[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4