On 20/11/2018 00:14, Chris Barker via Python-Dev wrote:
On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou <solipsis@pitrou.net> wrote:
I'd rather keep the reference to memory addressing than start doing car
analogies in the reference documentation.

I agree -- and any of the car analogies will probably be only valid in some jurisdictions, anyway.

I think being a bit more explicit about what properties an ID has, and how the id() function works, and we may not need an anlogy at all, it's not that difficult a concept. And methions that in c_python the id is (currently) the memory address is a good idea for those that will wonder about it, and if there is enough explanation, folks that don't know about memory addresses will not get confused.
...
I suggest something like the following:

"""
Every object has an identity, a type and a value. An object’s identity uniquely identifies the object. It will remain the same as long as that object exists. No two different objects will have the same id at the same time, but the same id may be re-used for future objects once one has been deleted. The ‘is’ operator compares the identity of two objects; the id() function returns an integer representing its identity. ``id(object_a) == id(object_b)`` if and only if they are the same object. 

**CPython implementation detail:** For CPython, id(x) is the memory address where x is stored.
"""
I agree that readers of a language reference should be able to manage without the analogies.

I want to suggest that identity and id() are different things.

The notion of identity in Python is what we access in phrases like "two different objects" and "the same object" in the text above. For me it defies definition, although one may make statements about it. A new object, wherever stored, is identically different from all objects preceding it.

Any Python has to implement the concept of identity in order to refer, without confusion, to objects in structures and bound by names. In practice, Python need only identify an object while the object exists in the interpreter, and the object exists as long as something refers to it in this way. To this extent, the identifier in the implementation need not be unique for all time.

The id() function returns an integer approximating this second idea. There is no mechanism to reach the object itself from the result, since it does not keep the object in existence, and worse, it may now be the id of a different object. In defining id(), I think it is confusing to imply that this number *is* the identity of the object that provided it.

Jeff Allen