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

[Steven D'Aprano]

On Tue, Jul 08, 2014 at 01:53:06AM +0200, Andreas Maier wrote:
> Thanks to all who responded.
> 
> In absence of class-specific equality test methods, the default 
> implementations revert to use the identity (=address) of the object as a 
> basis for the test, in both Python 2 and Python 3.

Scrub out the "= address" part. Python does not require that objects 
even have an address, that is not part of the language definition. (If I 
simulate a Python interpreter in my head, what is the address of the 
objects?) CPython happens to use the address of objects as their 
identity, but that is an implementation-specific trick, not a language 
guarantee, and it is documented as such. Neither IronPython nor Jython 
use the address as ID.


> In absence of specific ordering test methods, the default 
> implementations revert to use the identity (=address) of the object as a 
> basis for the test, in Python 2. 

I don't think that is correct. This is using Python 2.7:

py> a = (1, 2)
py> b = "Hello World!"
py> id(a) < id(b)
True
py> a < b
False

And just to be sure that neither a nor b are controlling this:

py> a.__lt__(b)
NotImplemented
py> b.__gt__(a)
NotImplemented


So the identity of the instances a and b are not used for < , although 
the identity of their types may be:

py> id(type(a)) < id(type(b))
False


Using the identity of the instances would be silly, since that would 
mean that sorting a list of mixed types would depend on the items' 
history, not their values.


> In Python 3, an exception is raised in that case.

I don't think the ordering methods are terribly relevant to the 
behaviour of equals.


> The bottom line of the discussion seems to be that this behavior is 
> intentional, and a lot of code depends on it.
> 
> We still need to figure out how to document this. Options could be:

I'm not sure it needs to be documented other than to say that the 
default object.__eq__ compares by identity. Everything else is, in my 
opinion, over-thinking it.


> 1. We define that the default for the value of an object is its 
> identity. That allows to describe the behavior of the equality test 
> without special casing such objects, but it does not work for ordering. 

Why does it need to work for ordering? Not all values define ordering 
relations.

Unlike type and identity, "value" does not have a single concrete 
definition, it depends on the class designer. In the case of object, the 
value of an object instance is itself, i.e. its identity. I don't think 
we need more than that.



-- 
Steven