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

[Finn Bock]

[Tim]

>Well, neither Java's hashCode nor identityHashCode are correct
>implementations of Python's id(), so JPython's id() is simply wrong. 

I agree.

>I don't know anything about the internals of JPython.  If there's a "choke  
>point" for allocating Python objects, 

The constructor of PyObject should do nicely.

>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.

Properly have to be a java long to avoid overflowing.

>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.

I haven't considered it to be so important. It is possible to fix the std
modules so it doesn't cause problems (as is done in cPickle.java). 

[Barry]

>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.

It properly isn't. New wrappers can be created for the same object. F.ex
when a java object is passed from python into java code and returned back
into python, two wrappers will exists for the same java object. Since these
two wrappers represent the same object they should (as it does now) return
the same id() value.

regards,
finn