Am 2014-07-08 01:50, schrieb Ethan Furman:
On 07/07/2014 04:36 PM, Andreas Maier wrote:
Am 2014-07-07 19:43, schrieb Ethan Furman:
Python cannot know which values are important in an equality test,
and which are not. So it refuses to guess.
Well, one could argue that using the address of an object for its
value equality test is pretty close to guessing,
considering that given a sensible definition of value equality,
objects of different identity can very well be equal but
will always be considered unequal based on the address.
And what would be this 'sensible definition'?
One that only a class designer can define. That's why I argued for
raising an exception if that is not defined.
But as I stated elsewhere in this thread: It is as it is, and we need to
document it.
So we have many cases of classes whose designers thought about
whether a sensible definition of equality was needed, and
decided that an address/identity-based equality definition was just
what they needed, yet they did not want to or could
not use the "is" operator?
1) The address of the object is irrelevant. While that is what
CPython uses, it is not what every Python uses.
2) The 'is' operator is specialized, and should only rarely be
needed. If equals is what you mean, use '=='.
3) If Python forced us to write our own __eq__ /for every single
class/ what would happen? Well, I suspect quite a few would make
their own 'object' to inherit from, and would have the fallback of
__eq__ meaning object identity. Practicality beats purity.
Can you give me an example for such a class (besides type object)?
(I.e. a class that does not have __eq__() and
__ne__() but whose instances are compared with == or !=)
I never add __eq__ to my classes until I come upon a place where I
need to check if two instances of those classes are 'equal', for
whatever I need equal to mean in that case.
With that strategy, you would not be hurt if the default implementation
raised an exception in case the two objects are not identical. ;-)
Ordering is much less frequent, and since we already tried always
ordering things, falling back to type name if
necessary, we have discovered that that is not a good trade-off. So
now if one tries to order things without
specifying how it should be done, one gets an exception.
In Python 2, the default ordering implementation on type object uses
the identity (address) as the basis for ordering.
In Python 3, that was changed to raise an exception. That seems to be
in sync with what you are saying.
Maybe it would have been possible to also change that for the default
equality implementation in Python 3. But it was
not changed. As I wrote in another response, we now need to document
this properly.
Doc patches are gratefully accepted. :)
Understood. I will be working on it. :-)
Andy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
