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

[Andreas Maier]

Am 2014-07-07 23:31, schrieb Rob Cliffe:
>
> On 07/07/2014 22:11, Jan Kaliszewski wrote:
>> [snip]
>>
>> IMHO, in Python context, "value" is a very vague term.  Quite often
>> we can read it as the very basic (but not the only one) notion of
>> "what makes objects being equal or not" -- and then saying that
>> "objects are compared by value" is a tautology.
>>
>> In other words, what object's "value" is -- is dependent on its
>> nature: e.g. the value of a list is what are the values of its
>> consecutive (indexed) items; the value of a set is based on values of
>> all its elements without notion of order or repetition; the value of
>> a number is a set of its abstract mathematical properties that
>> determine what makes objects being equal, greater, lesser, how
>> particular arithmetic operations work etc...
>>
>> I think, there is no universal notion of "the value of a Python
>> object".  The notion of identity seems to be most generic (every
>> object has it, event if it does not have any other property) -- and
>> that's why by default it is used to define the most basic feature of
>> object's *value*, i.e. "what makes objects being equal or not" (==
>> and !=).  Another possibility would be to raise TypeError but, as
>> Ethan Furman wrote, it would be impractical (e.g.
>> key-type-heterogenic dicts or sets would be practically impossible to
>> work with).  On the other hand, the notion of sorting order (< > <=
>> >=) is a much more specialized object property.
> Quite so.
>
> x, y = object(), object()
> print 'Equal:', ' '.join(attr for attr in dir(x) if
> getattr(x,attr)==getattr(y,attr))
> print 'Unequal:', ' '.join(attr for attr in dir(x) if
> getattr(x,attr)!=getattr(y,attr))
>
> Equal: __class__ __doc__ __new__ __subclasshook__
> Unequal: __delattr__ __format__ __getattribute__ __hash__ __init__
> __reduce__ __reduce_ex__ __repr__ __setattr__ __sizeof__ __str__
>
> Andreas, what attribute or combination of attributes do you think
> should be the "values" of x and y?
> Rob Cliffe
>
Whatever the object's type defines to be the value. Which requires the
presence of an __eq__() or __ne__() implementation.

I could even live with a default implementation on type object that ANDs
the equality of all instance data attributes and class data attributes,
but that is not possible because type object does not have a notion of
such data attributes.

Reverting to using the identity for the value of an instance of type
object is somehow helpless. It may make existing code work, but it is
not very logical. I could even argue it makes some logical code fail,
because while it reliably detects that the same objects are equal, it
fails to detect that different objects may also be equal (at least under
a sensible definition of value equality).

Having said all this: As a few people already wrote, we cannot change
the implementation within a major release. So the real question is how
we document it.

I'll try to summarize in a separate posting.

Andy