[Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)

[Tim Peters]

[Finn Bock, says id() is buggy under JPython]

[Tim]
>> Filed a bug report?

[Finn]
> Years ago <wink>:
>   http://www.python.org/jpython-bugs/incoming?id=118

>> In CPython, we just use the address of an object's header, and as CPython
>> never moves an object's header in memory, the good stuff follows
>> trivially.  Don't know what JPython tries to do, but it's bound to be
>> harder there (as Java can move memory around).

> That is also my guess. I cannot see what we can do about it, except
> inform users that not all python platform behave exactly the same. Which
> is why I brought it up.

Well, neither Java's hashCode nor identityHashCode are correct
implementations of Python's id(), so JPython's id() is simply wrong.  I
don't know anything about the internals of JPython.  If there's a "choke
point" for allocating Python objects, the quickest way out may be to add a
write-once "id" field to each Python object under JPython, and simply fill
it with an integer that's (safely) incremented by 1 on each allocation.

Python doesn't guarantee you'll get the *same* id(x) across implementations,
or even across runs under a single implementation, so the implementations of
id() in CPython and JPython can do entirely different things.  They have to
meet the promises in the Python docs, though, and JPython's currently
doesn't.