[Python-Dev] == on object tests identity in 3.x
andreas.r.maier at gmx.de
Tue Jul 8 03:18:16 CEST 2014
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
>> 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. :-)
More information about the Python-Dev