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
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,
Op 2005-06-08, Mahesh schreef <[EMAIL PROTECTED]>:
> 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
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__ methods work. They don't make any
On Wed, 08 Jun 2005 11:01:27 -0700, Mahesh wrote:
> 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.
Why should Python assume that != means "not is" instead o
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,
> return its negation?
>
> Act
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? Surely its completely incons
Can anybody please give me a decent justification for this:
class A(object):
def __init__(self, a):
self.a = a
def __eq__(self, other):
return self.a == other.a
s = A(3)
t = A(3)
>>> print s == t
True
>>> print s != t
True
I just spent a long, long time tracking down a
47 matches
Mail list logo
