Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Object identity has no necessary connection to memory location (was: What is a function parameter =[] for?)
Date: Thu, 26 Nov 2015 22:49:14 +1100
Lines: 49
Message-ID: <mailman.133.1448538927.20593.python-list@python.org>
References: <n32jqq$k4j$1@dont-email.me> <mailman.35.1448400323.20593.python-list@python.org> <56550273$0$1585$c3e8da3$5496439d@news.astraweb.com> <mailman.64.1448445391.20593.python-list@python.org> <5655f27b$0$1614$c3e8da3$5496439d@news.astraweb.com> <w2dh9k9bjhq.fsf@daphne.csail.mit.edu> <mailman.109.1448504727.20593.python-list@python.org> <w2dd1uxbd1c.fsf@daphne.csail.mit.edu> <6imd5b9it55sucrcl95o95tppro7errfsi@4ax.com> <871tbdf2o0.fsf@elektro.pacujo.net> <70qd5b9lbtjlsotn7d21gor4rd67o79ou7@4ax.com> <85lh9l9f6e.fsf_-_@benfinney.id.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <85lh9l9f6e.fsf_-_@benfinney.id.au>
Precedence: list
Xref: csiph.com comp.lang.python:99564

On Thu, Nov 26, 2015 at 10:24 PM, Ben Finney <ben+python@benfinney.id.au> w=
rote:
> Dave Farrance <df@see.replyto.invalid> writes:
>
>> Marko Rauhamaa <marko@pacujo.net> wrote:
>>
>> >Dave Farrance <df@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".)
>> >
>> >What's a faked id?
>>
>> You can figure out what I'm getting at -- i.e. I presume that the ids
>> are not pointers to stored numbers in memory (as with CPython) but are
>> a translation of the numerical variable's value.
>
> Why refer to that as =E2=80=9Cfaked=E2=80=9D? That's what I can't figure =
out about what
> you're getting at. Perhaps Marko shares my uncomprehension.
>
> The Python language makes no promise about =E2=80=9Cpointers to stored nu=
mbers
> in memory=E2=80=9D for object identity. That is an implementation detail =
of
> CPython, and is *explicitly* not promised for any other Python
> implementation.
>
> If you are surprised that object identity appears to have no connection
> with memory location, then you've made unwarranted assumptions that are
> explicitly warned against in the Python documentation.

I can't remember which language it was (maybe Lua?), but I know
there's one that uses a machine word to store either a pointer to a
heap object, or an integer of at most one less bit than the machine
word, represented by 2*n+1. A system like this would work for Python
object IDs; it guarantees that all heap objects have unique even IDs
(because no two can share the same address; all it takes is requiring
16-bit alignment, and most modern CPUs will give at least 32-bit), and
all small integers will be slotted in between them. So the integer
objects might themselves be entirely faked, never actually existing in
memory, yet never violating the rule of object IDs. (Any integer too
big to fit in a machine word minus one bit would be heap-allocated, so
they're safe.)

That's "faked", in a sense, but still perfectly compliant.

ChrisA