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

[Stephen J. Turnbull]

Andreas Maier writes:

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

I noticed this a long time ago and just decided it was covered by
"consenting adults".  That is, if the "sensible definition" of x == y
is such that it can be true simultaneously with x != y, it's the
programmer's responsibility to notice that, and to provide an
implementation.  But there's no issue that lack of an explicit
implementation of comparison causes a program to have ambiguous
meaning.

I also consider that for "every object has a value" to make sense as a
description of Python, that value must be representable by an object.
The obvious default representation for the value of any object is the
object itself!

Now, for this purpose you don't need a "canonical representation" of
an object's value.  In particular, equality comparisons need not
explicitly construct a representative object.  Some do, some don't, I
would suppose.  For example, in comparing an integer with a float, I
would convert the integer to float and compare, but in comparing float
and complex I would check the complex for x.im == 0.0, and if true,
return the value of x.re == y.

I'm not sure how you interpret "value" to find the behavior of Python
(the default comparison) problematic.  I suspect you'd have a hard
time coming up with an interpretation consistent with Python's object
orientation.

That said, it's probably worth documenting, but I don't know how much
of the above should be introduced into the documentation.

Steve