Tim Chase python.list at
Wed Mar 5 19:12:54 CET 2014

On 2014-03-05 09:40, Rustom Mody wrote:
> Every object has an identity, a type and a value. An object's
> identity never changes once it has been created; you may think of
> it as the object's address in memory. The 'is' operator compares
> the identity of two objects; the id() function returns an integer
> representing its identity (currently implemented as its address).
> from

Note the "currently", which does not mean "now, always, and forever
for every implementation".


    Return the “identity” of an object. This is an integer which is
    guaranteed to be unique and constant for this object during its
    lifetime. Two objects with non-overlapping lifetimes may have the
    same id() value.

    CPython implementation detail: This is the address of the object
    in memory.

This is clearly documented as a *CPython implementation detail*.  The
id() function is free to return sequential integers, arbitrary
integers, memory addresses, GUIDs-as-integers, or hashes-as-integers
for some internal representation.

The only thing that matters is (1) that id() returns *some* integer
identifying the object, and (2) the ability to compare id(thing1) with
id(thing2) and see if they are the same or different (assuming thing1
and thing2 share lifetimes during their id() calls), regardless of
what is actually returned.

> So when you say
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. 
> well... all I can say is I dont know what to say :-)

That you live in a CPython world, unencumbered by experience in other
flavors of language-spec-compliant Python interpreters where id()
returns integers that *aren't* memory addresses?


More information about the Python-list mailing list