[Python-Dev] == on object tests identity in 3.x (original) (raw)

Steven D'Aprano steve at pearwood.info
Tue Jul 8 04:32:34 CEST 2014

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

More information about the Python-Dev mailing list