[Python-Dev] == on object tests identity in 3.x

[Andreas Maier]

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