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 satisfy
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 known
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
ofis conceptually distinct from ordering in a sorted list, even
though the
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
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 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 ordering would be to
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 mathematical size.
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?), ordering (in a
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 which should
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 close) and the
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 soon as
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
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 not hashable?
The purpose of
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 are
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, which
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 got that: use
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 bug
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
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?
Actually,
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
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
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
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 compared
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
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
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 =
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 thats
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
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
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 seems quite silly
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 seems
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
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
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 == and
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
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
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.
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
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
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 be
40 matches
Mail list logo
