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

[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.