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

Andreas Maier andreas.r.maier at gmx.de
Tue Jul 8 01:55:55 CEST 2014

Am 2014-07-08 01:49, schrieb Benjamin Peterson:
> On Mon, Jul 7, 2014, at 16:36, Andreas Maier wrote:
>> Am 2014-07-07 19:43, schrieb Ethan Furman:
>>> On 07/07/2014 09:56 AM, Andreas Maier wrote:
>>>> Am 07.07.2014 17:55, schrieb Ethan Furman:
>>>>> On 07/07/2014 04:22 AM, Andreas Maier wrote:
>>>>>> Where is the discrepancy between the documentation of == and its
>>>>>> default implementation on object documented?
>>>>> There's seems to be no discrepancy (at least, you have not shown it),
>>>> The documentation states consistently that == tests the equality of
>>>> the value of an object. The default implementation
>>>> of == in both 2.x and 3.x tests the object identity. Is that not a
>>>> discrepancy?
>>> One could say that the value of an object is the object itself. Since
>>> different objects are different, then they are not equal.
>>>>> but to answer the question about why the default equals operation is an
>>>>> identity test:
>>>>>     - all objects should be equal to themselves (there is only one that
>>>>> isn't, and it's weird)
>>>> I agree. But that is not a reason to conclude that different objects
>>>> (as per their identity) should be unequal. Which is
>>>> what the default implementation does.
>>> 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.
> Probably the best argument for the behavior is that "x is y" should
> imply "x == y", which preludes raising an exception. No such invariant
> is desired for ordering, so default implementations of < and > are not
> provided in Python 3.
I agree that "x is y" should imply "x == y".
The problem of the default implementation is that "x is not y" implies 
"x != y" and that may or may not be true under a sensible definition of 

More information about the Python-Dev mailing list