>>>>> "TP" == Tim Peters <tim_one@email.msn.com> writes:
TP> Well, neither Java's hashCode nor identityHashCode are correct
TP> implementations of Python's id(), so JPython's id() is simply
TP> wrong. I don't know anything about the internals of JPython.
TP> If there's a "choke point" for allocating Python objects, the
TP> quickest way out may be to add a write-once "id" field to each
TP> Python object under JPython, and simply fill it with an
TP> integer that's (safely) incremented by 1 on each allocation.
TP> Python doesn't guarantee you'll get the *same* id(x) across
TP> implementations, or even across runs under a single
TP> implementation, so the implementations of id() in CPython and
TP> JPython can do entirely different things. They have to meet
TP> the promises in the Python docs, though, and JPython's
TP> currently doesn't.
I can't generate patches right now, but what you need to change is in
__builtin__.java, the id() function. It should probably call
object.id() which would fill in the monotonically incrementing id as
Tim suggestions.
One question is what to do about Java proxies. Currently built-in
id() returns the identityHashCode() of the proxy object, which is just
an Object. I'm not sure sticking the id in the wrapper is the right
thing or not.
-Barry
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