On 09Feb2024 18:56, Left Right wrote:
But, more to the point: extending collections.abc.Mapping may or may
not be possible in OP's case.
We don't yet know if that's what the OP had in mind yet, anyway.
Also, if you are doing this through inheritance, this seems really
convoluted: why not jus
> Looks like it can simply be done in Python, no tp_as_mapping needed.
It's not that it isn't needed. You've just shown a way to add it using
Python code.
But, more to the point: extending collections.abc.Mapping may or may
not be possible in OP's case.
Also, if you are doing this through inheri
Left Right via Python-list schreef op 9/02/2024 om 17:09:
In order for the "splat" operator to work, the type of the object must
populate slot `tp_as_mapping` with a struct of this type:
https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and
have some non-null implementations of the
In order for the "splat" operator to work, the type of the object must
populate slot `tp_as_mapping` with a struct of this type:
https://docs.python.org/3/c-api/typeobj.html#c.PyMappingMethods and
have some non-null implementations of the methods this struct is
supposed to contain.
I can do this i
Chris Angelico writes:
> On 08Feb2024 12:21, tony.fl...@btinternet.com
wrote:
> >I know that mappings by default support the ** operator, to unpack the
> >mapping into key word arguments.
> >
> >Has it been considered implementing a dunder method for t
On Fri, 9 Feb 2024 at 17:03, Cameron Simpson via Python-list
wrote:
>
> On 08Feb2024 12:21, tony.fl...@btinternet.com
> wrote:
> >I know that mappings by default support the ** operator, to unpack the
> >mapping into key word arguments.
> >
> >Has it been consid
On 08Feb2024 12:21, tony.fl...@btinternet.com wrote:
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.
Has it been considered implementing a dunder method for the **
operator so you could unpack an object into a key word argument, and
I know that mappings by default support the ** operator, to unpack the
mapping into key word arguments.
Has it been considered implementing a dunder method for the ** operator
so you could unpack an object into a key word argument, and the
developer could choose which keywords would be
thanks everybody.
--
http://mail.python.org/mailman/listinfo/python-list
On Fri, 22 Aug 2008 00:35:31 -0700 (PDT), akva <[EMAIL PROTECTED]> wrote:
>
> well, frankly I expected a |= b to mean exactly the same as a = a | b
> regardless of the object type.
So did I. I'm glad your post called this to my attention; I
recently told my kid exactly that wrong thing.
--
To
akva wrote:
could you please refer me a link where this is specified? I couldn't
find it in python documentation
http://docs.python.org/ref/augassign.html
"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
thanks all,
>Yes. That's the exact purpose of the in-place operators when they deal with
>mutable objects. What else did you expect?
well, frankly I expected a |= b to mean exactly the same as a = a | b
regardless of the object type.
> The manual explicitly specifies that mutable objects may imp
akva wrote:
Hi All,
what's the exact semantics of the |= operator in python?
It seems that a |= d is not always equivalent to a = a | d
The manual explicitly specifies that mutable objects may implement the
operation part of operation-assignments by updating in place -- so that
akva wrote:
> Hi All,
>
> what's the exact semantics of the |= operator in python?
> It seems that a |= d is not always equivalent to a = a | d
>
> For example let's consider the following code:
>
> def foo(s):
>s = s | set([10])
>
> def ba
Hi All,
what's the exact semantics of the |= operator in python?
It seems that a |= d is not always equivalent to a = a | d
For example let's consider the following code:
def foo(s):
s = s | set([10])
def bar(s):
s |= set([10])
s = set([1,2])
foo(s)
print s # prints set([1,
Paul Boddie <[EMAIL PROTECTED]> wrote:
> However, this ambiguous usage of * and ** is one thing I don't recall
> appearing on any of the "Python warts" lists
It is true that the same punctuation character is used in more than one
context, but that is also true for many other punctuation character
Robert Dailey wrote:
> I noticed that the ** operator is used as the power operator, however
> I've seen it used when passing variables into a function.
Others have already pointed out the relevant documentation. However,
this ambiguous usage of * and ** is one thing I don't rec
On Jul 16, 10:40 am, Robert Dailey <[EMAIL PROTECTED]> wrote:
> I noticed that the ** operator is used as the power operator, however
> I've seen it used when passing variables into a function. For example,
> I was researching a way to combine dictionaries. I found that if
En Mon, 16 Jul 2007 14:40:14 -0300, Robert Dailey <[EMAIL PROTECTED]>
escribió:
> I noticed that the ** operator is used as the power operator, however
> I've seen it used when passing variables into a function. For example,
> I was researching a way to combine dictionaries.
Robert Dailey <[EMAIL PROTECTED]> wrote:
> However, I have no idea what the
> ** operator is here. I know that when you specify ** as a parameter in
> a function definition, it represents a dictionary of parameters passed
> in. However, in this example it is NOT being
Robert Dailey schrieb:
> I noticed that the ** operator is used as the power operator, however
> I've seen it used when passing variables into a function. For example,
> I was researching a way to combine dictionaries. I found that if you
> do this:
>
> a = {"t1&qu
I noticed that the ** operator is used as the power operator, however
I've seen it used when passing variables into a function. For example,
I was researching a way to combine dictionaries. I found that if you
do this:
a = {"t1":"a", "t2":"b"}
b = {&qu
Tuvas wrote:
> What exactly does the ^ operator do? I've seen, for example, that
> 3^4=7, 3^5=8. but 3^3=0. Is it just adding them together if they are
> not equal, and if they are equal, outputs 0, or what? Thanks!
>
^ is the "bit XOR" operation. It treats its left an
Thanks alot! That sure makes lots of sense!
--
http://mail.python.org/mailman/listinfo/python-list
Tuvas wrote:
> What exactly does the ^ operator do? I've seen, for example, that
> 3^4=7, 3^5=8. but 3^3=0. Is it just adding them together if they are
> not equal, and if they are equal, outputs 0, or what? Thanks!
It performs an "exclusive-OR" (XOR) operation on the bi
What exactly does the ^ operator do? I've seen, for example, that
3^4=7, 3^5=8. but 3^3=0. Is it just adding them together if they are
not equal, and if they are equal, outputs 0, or what? Thanks!
--
http://mail.python.org/mailman/listinfo/python-list
Max wrote:
> Jordan Rastrick wrote:
>> Well, never, ever use equality or inequality operations with floating
>> point numbers anyway, in any language, as they are notoriously
>> unreliable due to the inherent inaccuracy of floating point. Thats
>> another pitfall, I'll grant, but its a pretty well
Jordan Rastrick wrote:
> I don't want to order the objects. I just want to be able to say if one
> is equal to the other.
>
> Here's the justification given:
>
> The == and != operators are not assumed to be each other's
> complement (e.g. IEEE 754 floating point numbers do not satisf
Before I answer, let me clarify my position. I am NOT advocating any
change for the 2.x series. I'm not even forwarding any particular
proposal for 3.0/3000. My key (and close to sole) point is that behavior
of > & < is conceptually distinct from ordering in a sorted list, even
though the beha
Dan Sommers wrote:
> Let the DB-API do more work for you:
>
> cursor = connection.cursor( )
> sql = """SELECT column2, columns3 FROM table WHERE name LIKE %s"""
> values = ('%%%s%%' % searchterm,) # note that this is a tuple
It l
Dan Sommers wrote:
> On Mon, 13 Jun 2005 15:12:54 GMT,
> William Gill <[EMAIL PROTECTED]> wrote:
>
>
>>I am using the % operator to create queries for a db app. It works fine
>>when exact strings, or numbers are used, but some queries need partial
>>matching
On Mon, 13 Jun 2005 15:12:54 GMT,
William Gill <[EMAIL PROTECTED]> wrote:
> I am using the % operator to create queries for a db app. It works fine
> when exact strings, or numbers are used, but some queries need partial
> matching that use the '%' as a wildcards. So
> to return 'WHERE name LIKE %smith%'I have tried using escapes,
> character codes for the % sign, and lots of other gyrations with no
> success. The only thing that works is if I modify searchterm first:
>
>searchterm = 'smith'
>searchterm ='%'+'smith'+'%'
>sql += 'WHE
William Gill wrote:
> I am using the % operator to create queries for a db app. It works fine
> when exact strings, or numbers are used, but some queries need partial
> matching that use the '%' as a wildcards. So for example the resultant
> string should be 'WHERE
I am using the % operator to create queries for a db app. It works fine
when exact strings, or numbers are used, but some queries need partial
matching that use the '%' as a wildcards. So for example the resultant
string should be 'WHERE name LIKE %smith%' (would match
If a behavior change is possible at all, I think a more reasonable
behavior would be:
if any rich comparison methods are defined, always use rich comparisons
(and throw an exception if the required rich comparison method is not
available).
This would at least have the benefit of letting users kno
Robert Kern <[EMAIL PROTECTED]> writes:
> greg wrote:
>> David M. Cooke wrote:
>>
To solve that, I would suggest a fourth category of "arbitrary
ordering", but that's probably Py3k material.
>>>
>>>We've got that: use hash().
>>>[1+2j, 3+4j].sort(key=hash)
>> What about objects that are no
On Fri, 10 Jun 2005 09:50:56 -0500,
Rocco Moretti <[EMAIL PROTECTED]> wrote:
> Dan Sommers wrote:
>> On Thu, 09 Jun 2005 15:50:42 +1200,
>> Greg Ewing <[EMAIL PROTECTED]> wrote:
>>
>>> Rocco Moretti wrote:
>>>
The main problem is that Python is trying to stick at least three
different
George Sakkis wrote:
> "Rocco Moretti" wrote:
>
>
>>One way to handle that is to refuse to sort anything that doesn't have a
>>"natural" order. But as I understand it, Guido decided that being able
>>to sort arbitrary lists is a feature, not a bug.
>
>
> He has changed his mind since then
> (ht
"Rocco Moretti" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The "wackyness" I refered to wasn't that a list of complex numbers isn't
> sortable, but the inconsistent behaviour of list sorting. As you
> mentioned, an arbitraty collection of objects in a list is sortable, but
> as
On 10 Jun 2005 09:05:53 -0700, Dan Bishop <[EMAIL PROTECTED]> wrote:
>Steven D'Aprano wrote:
>...
>> If you were to ask, "which is bigger, 1+2j or 3+4j?" then you
>> are asking a question about mathematical size. There is no unique answer
>> (although taking the absolute value must surely come clos
Steven D'Aprano wrote:
...
> If you were to ask, "which is bigger, 1+2j or 3+4j?" then you
> are asking a question about mathematical size. There is no unique answer
> (although taking the absolute value must surely come close) and the
> expression 1+2j > 3+4j is undefined.
>
> But if you ask "whic
"Rocco Moretti" wrote:
> One way to handle that is to refuse to sort anything that doesn't have a
> "natural" order. But as I understand it, Guido decided that being able
> to sort arbitrary lists is a feature, not a bug.
He has changed his mind since then
(http://mail.python.org/pipermail/python
Dan Sommers wrote:
> On Thu, 09 Jun 2005 15:50:42 +1200,
> Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>
>>Rocco Moretti wrote:
>>
>>>The main problem is that Python is trying to stick at least three
>>>different concepts onto the same set of operators: equivalence (are
>>>these two objects the same?
On Thu, 09 Jun 2005 08:10:09 -0400, Dan Sommers wrote:
>>> The main problem is that Python is trying to stick at least three
>>> different concepts onto the same set of operators: equivalence (are
>>> these two objects the same?), ordering (in a sorted list, which comes
>>> first?), and mathematic
greg wrote:
> David M. Cooke wrote:
>
>>>To solve that, I would suggest a fourth category of "arbitrary
>>>ordering", but that's probably Py3k material.
>>
>>We've got that: use hash().
>>[1+2j, 3+4j].sort(key=hash)
>
> What about objects that are not hashable?
>
> The purpose of arbitrary order
David M. Cooke wrote:
>>To solve that, I would suggest a fourth category of "arbitrary
>>ordering", but that's probably Py3k material.
>
> We've got that: use hash().
> [1+2j, 3+4j].sort(key=hash)
What about objects that are not hashable?
The purpose of arbitrary ordering would be to provide
an
Greg Ewing <[EMAIL PROTECTED]> writes:
> Rocco Moretti wrote:
>
> > This gives the wacky world where
>> "[(1,2), (3,4)].sort()" works, whereas "[1+2j, 3+4j].sort()" doesn't.
>
> To solve that, I would suggest a fourth category of "arbitrary
> ordering", but that's probably Py3k material.
We've g
On Thu, 09 Jun 2005 15:50:42 +1200,
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Rocco Moretti wrote:
>> The main problem is that Python is trying to stick at least three
>> different concepts onto the same set of operators: equivalence (are
>> these two objects the same?), ordering (in a sorted list,
already smart. It deduces what you want with the += operator
even if you haven't defined an __iadd__ method. If python can be smart
with that, I don't see python being smart with !=.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Rocco Moretti wrote:
> The main problem is that Python is trying to stick at least three
> different concepts onto the same set of operators: equivalence (are
> these two objects the same?), ordering (in a sorted list, which comes
> first?), and mathematical "size".
A possible compromise would
Jordan Rastrick wrote:
> Where are the 'number of situations' where __ne__ cannot be derived
> from __eq__? Is it just the floating point one? I must admit, I've
> missed any others.
The floating point one is just an example, it's not meant
to be the entire justification.
Some others:
* Numeric
Jordan Rastrick wrote:
> But I explicitly provided a method to test equality.
Actually, no, you didn't. You provided a method to define
the meaning of the operator spelled '==' when applied to your
object. That's the level of abstraction at which Python's
__xxx__ m
ot is" instead of "not equal"?
That seems like an especially perverse choice given that the operator is
actually called "not equal".
> So, s != t is True because the ids of the two objects are different.
> The same applies to, for example s > t and s < t. Do you
Robert Kern wrote:
> The problem arises that, in the presence of rich comparisons, (a == b)
> is not always a boolean value, while (a is b) is always a boolean value.
But that still doesn't mean that in a case where a == b (via __eq__)
returns a non-boolean, __ne__ would not be defined as well.
Christopher Subich wrote:
> Perhaps the language should offer
> the sensible default of (!=) == (not ==) if one of them but not the
> other is overriden, but still allow overriding of both.
I believe that's exactly what Jordan is promoting and, having been
bitten in exactly the same way I would
Mahesh wrote:
> I understand that what makes perfect sense to me might not make perfect
> sense to you but it seems a sane default. When you compare two objects,
> what is that comparision based on? In the explicit is better than
> implicit world, Python can only assume that you *really* do want to
"Jordan Rastrick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Well, I'll admit I haven't ever used the Numeric module, but since
> PEP207 was submitted and accepted, with Numeric as apparently one of
> its main motivations, I'm going to assume that the pros and cons for
> having
I understand that what makes perfect sense to me might not make perfect
sense to you but it seems a sane default. When you compare two objects,
what is that comparision based on? In the explicit is better than
implicit world, Python can only assume that you *really* do want to
compare objects unles
Jordan Rastrick wrote:
> Mahesh raised the argument some posts back that Python should not 'just
> guess' what you want. But the problem is, it *already does* - it
> guesses you want object identity comparison if you haven't written
> __ne__. But if __ne__ is not provided, than the negation of
>
I'm a Maths and Philosophy undergraduate first and foremost, with
Computer Science as a tacked on third; I've studied a fair bit of logic
both informally and formally, and am familiar with things such as the
non-nessecity of the law of the excluded middle in an arbitrary
propositional calculus farm
Peter Hansen wrote:
> I can see only one comment that seems to describe that situation,
where it refers to "IEEE 754 floating point numbers do not satisfy [==
being the complement of !=]".
>
> (Though that may be justification enough for the feature...)
To my naive eye, that possibility see
Matt Warden wrote:
> Jordan,
>
> On 8 Jun 2005 11:44:43 -0700, Jordan Rastrick
> <[EMAIL PROTECTED]> wrote:
>
>>But I explicitly provided a method to test equality. And look at the
>>plain english meaning of the term "Not equals" I think its pretty
>>reasonable
>
>
> Indeed. Furthermore, it see
Jordan Rastrick wrote:
> Just because a behaviour is documented, doesn't mean its not counter
> intutitive, potentially confusing, and unnessecary.
>
> I have spent a fair amount of time reading the Python docs. I have not
> yet memorised them. I may have read this particular section of the
> ref
Well, I'll admit I haven't ever used the Numeric module, but since
PEP207 was submitted and accepted, with Numeric as apparently one of
its main motivations, I'm going to assume that the pros and cons for
having == and ilk return things other than True or False have already
been discussed at length
"Jordan Rastrick" wrote:
> I'd suggest the only nessecary change is, if objects a,b both define
> __eq__ and not __ne__, then a != b should return not (a == b)
>
> If a class defines __ne__ but not __eq__, well that seems pretty
> perverse to me. I don't especially care one way or another how that
Jordan Rastrick wrote:
> Are there any other reasonable examples people can give where it makes
> sense for != and == not to be each other's complement?
__eq__ and __ne__ implement *rich* comparisons. They don't have to
return only True or False.
In [1]:import Numeric
In [2]:a = Numeric.array(
Jordan,
On 8 Jun 2005 11:44:43 -0700, Jordan Rastrick
<[EMAIL PROTECTED]> wrote:
> But I explicitly provided a method to test equality. And look at the
> plain english meaning of the term "Not equals" I think its pretty
> reasonable
Indeed. Furthermore, it seems quite silly that these would be di
I'd suggest the only nessecary change is, if objects a,b both define
__eq__ and not __ne__, then a != b should return not (a == b)
If a class defines __ne__ but not __eq__, well that seems pretty
perverse to me. I don't especially care one way or another how thats
resolved to be honest.
The order
"Jordan Rastrick" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Well, I don't really want the objects to be comparable. In fact, to
> quote that PEP you linked:
>
> An additional motivation is that frequently, types don't have a
> natural ordering, but still need to be co
Jordan Rastrick wrote:
> Unless someone can explain some sort of problem that arises from having
> != take advantage of a __eq__ method where present, I'd suggest that it
> should do so in Python 2.5.
If you're serious about this proposal, please formalize it in a PEP.
Things to specify:
How ex
Just because a behaviour is documented, doesn't mean its not counter
intutitive, potentially confusing, and unnessecary.
I have spent a fair amount of time reading the Python docs. I have not
yet memorised them. I may have read this particular section of the
reference manual, or I may have not, I
Fredrik Lundh wrote:
> for a number of situations where __ne__ cannot be derived from __eq__,
> see:
>
> http://www.python.org/peps/pep-0207.html
That "number" being "one"?
I can see only one comment that seems to describe that situation, where
it refers to "IEEE 754 floating point numbers
Well, I don't really want the objects to be comparable. In fact, to
quote that PEP you linked:
An additional motivation is that frequently, types don't have a
natural ordering, but still need to be compared for equality.
Currently such a type *must* implement comparison and thus
Mahesh wrote:
> No, why should Python assume that if you use != without supplying a
> __ne__ that this is what you want?
Because every single time I've used __ne__, that *is* what I want.
> Without direction it will compare
> the two objects which is the default behavior.
It's also the default b
No, why should Python assume that if you use != without supplying a
__ne__ that this is what you want? Without direction it will compare
the two objects which is the default behavior.
So, s != t is True because the ids of the two objects are different.
The same applies to, for example s > t and s
Jordan Rastrick wrote:
> I just spent a long, long time tracking down a bug in a program that
> results from this behaviour.
>
> Surely the != operator should, if no __ne__ method is present for
> either object, check to see if an __eq__ method is defined, and if so,
> r
Jordan Rastrick wrote:
> Surely the != operator should, if no __ne__ method is present for
> either object, check to see if an __eq__ method is defined, and if so,
> return its negation?
>
> Actually, that brings me to a wider question - why does __ne__ exist at
> all? Sur
me tracking down a bug in a program that
results from this behaviour.
Surely the != operator should, if no __ne__ method is present for
either object, check to see if an __eq__ method is defined, and if so,
return its negation?
Actually, that brings me to a wider question - why does __ne__ exist
79 matches
Mail list logo
