RetroSearch Browse

Wed Aug 6 22:13:48 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-August/037510.html

"Tim Peters" <tim.one at comcast.net> wrote in message
news:BIEJKCLHCIOIHAGOKOLHMEMPGIAA.tim.one at comcast.net...
> The docs for id() just promise a unique integer; it needn't be a
memory
> address.

"Martin v. Löwis" <martin at v.loewis.de> wrote in message
news:m3r83yfs8a.fsf at mira.informatik.hu-berlin.de...
> The Java VM
> certainly has a unique (among "life" objects) identification of
> objects, which likely also fits into a fixed number of bytes.

But does not need to.

> Interpret these bytes as a number.

Same idea I had.

"Samuele Pedroni" <pedronis at bluewin.ch> wrote in message
news:5.2.1.1.0.20030806224144.02692178 at pop.bluewin.ch...

>at each time objects have all different addresses, which does not
mean
>that an object will not have the same address that some other object,
even
>still alive, had at some time in the past.

Remove 'even still alive' and the same is true of CPython, leading
some newbies to misunderstand why id([])==id([]) can be true.

> Identity distinguishability and
>identity as a number are not the same. If you want identity as a
number you
>should do some work.

Can't parse this.

(repeat of Lowis)>>The Java VM
>>certainly has a unique (among "life" objects) identification of
>>objects, which likely also fits into a fixed number of bytes.

>why do you think it certainly have to. It doesn't.

Which does it not have?  unique id info or fixed # of bytes?

When Jython (or any Python interpreter acting through physical means)
binds a Py object to a 'target' (name or slot), it would naively seem
that it must store *some* sort of permanent information, unique for
each object, that enables the interpreter to reliably access that
particular object.  If so, Martin (and I) are suggesting to turn that
info into an id integer.  (The conversion need not even be
invertible).

An alternative, if there is *no* permanent access information for an
object, because gc updates *all* refs after moving an object, is an id
field as part of the object header.  I can see that could be a
nuisance for something that is almost not needed.

Terry J. Reedy

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-August/037510.html below:

[Python-Dev] Re: sizeof(long) != sizeof(void*)