Object identity has no necessary connection to memory location

Steven D'Aprano steve at pearwood.info
Thu Nov 26 21:17:53 EST 2015


On Fri, 27 Nov 2015 07:00 am, Ben Finney wrote:

> Dave Farrance <df at see.replyto.invalid> writes:
> 
>> >> >Dave Farrance <df at see.replyto.invalid>:
>> >> >
>> >> >> (Conversely, I see that unlike CPython, all PyPy's numbers have
>> >> >> unchanging ids, even after exiting PyPy and restarting, so it seems
>> >> >> that PyPy's numerical ids are "faked".)
>>
>> Hence
>>
>> https://en.wikipedia.org/wiki/Scare_quotes
> 
> I saw the scare quotes. They still communicate your position that object
> identity “should” be reliably connected to the object's memory location.
> 
> Either you don't hold that position, in which case your original
> statement was as ambiguous as this most recent one you wrote; or you do
> hold that position, and my response stands.


Ben is right that object IDs are not promised to have any connection to
object memory location. In Jython and IronPython, for example, objects
appear to be given sequential IDs based on when you first ask for their ID.
This is in IronPython:

>>> a = []
>>> b = []
>>> id(b)
43
>>> id(a)
44


Jython is similar, except the IDs are 1 and 2 rather than 43 and 44. (All
these results are subject to change, of course.)

But (I think) that Dave is right that PyPy fakes IDs, in the sense that
objects can be destroyed and recreated behind the scenes in PyPy without
your knowledge.

As I understand it, what appears to be happening is that PyPy can take
Python objects, convert them to low-level machine values (destroying the
Python object in the process), perform processing on the machine values,
and recreate the Python object before you know it is gone. The consequence
of that is that what we see as a single Python object with a fixed lifespan
may in fact be multiple objects with much shorter lifespans.

I'm rather partial to science fiction analogies, so here is one: when
Captain Kirk uses the transporter to beam down to the Planet Of Hot Space
Babes Wearing Hats With A Moral Lesson For Us All, we see Kirk on the
Enterprise disappear and then re-appear on the planet a moment later. As
far as we are concerned, and as far as Kirk is concerned, he has existed
the whole time he was in transport. If he had an itchy nose just as he
left, it's still itchy when he arrives, and if he is transported
mid-thought, he finishes the thought when he arrives. There's no perception
of discontinuity.

But as Scotty well knows, in fact Kirk's entire body is ripped into atoms by
the transporter beam, utterly destroying Kirk in the process, then
transported via some oh-so-clever quantum-magical^W quantum-mechanical
trick, to be reassembled at the other end. Although Kirk doesn't feel like
he ceased to exist and then was re-created, in fact that's exactly what
happened. One second after arriving on the planet, Kirk's body is now
precisely one second old. It may not even be made of the same atoms that
his former body was made of.

In PyPy, an object's lifetime is not necessarily the same as the lifetime of
the actual block of memory used for that object. Not only might objects be
relocated in space (as they can be in IronPython and Jython) but in time as
well.



-- 
Steven




More information about the Python-list mailing list