Explanation of list reference

Grant Edwards invalid at invalid.invalid
Sat Feb 15 14:02:35 EST 2014


On 2014-02-15, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody <rustompmody at gmail.com> wrote:
>>> To start with we say two objects are identical if they have the same
>>> memory address.
>>
>> This is false.  It happens to hold for CPython, but that's an
>> implementation detail.  The definition of object identity does not
>> depend on memory address.  It also doesn't have anything to do with
>> space-time coordinates.  The concept of object identity is an
>> abstraction, not an analogy from physics.
>
> With the restrictions of computer memory, I suspect that two objects
> with the same address must be identical,

That's true if they have the same address _at_the_exact_same_time_.

[AND IF the two chunks of code evaluating the addresses of the objects
share a machine-level address space -- which I doubt is actually
required by the Python language definition. It would be difficult
(but not impossible) to implement a Python where that wasn't true.]

However, it's possible for object 1 to have address XYZ at one point
in time and object 2 to have address XYZ at a different point in time
even though object 1 and object 2 are different objects.

The tricky bit is that those two points in time may occur at adjacent
"lines" when your program is executing.  They may even occur at two
different points within the same line of code.  IOW, there's just no
reason to assume that:

 address_of(object1) == address_of(ojbect2)

is equivalent to 

 object1 is object2

Garbage collection could kick in after the evaluation of
address_of(object1) and before the evaluation of address_of(object2)
with the result that the two objects would appear to have the same
address in memory.

So, unless you're working on the guts of a Python implementation
you've got to just plain stop thinking about memory addresses.
Period.
 
-- 
Grant




More information about the Python-list mailing list