Issue222789

classification
Title: __builtin__.id() does not return unique values for different
Type: Severity: normal
Components: Core Versions:
Milestone:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: pedronis Nosy List: bckfnn, cgroves, gbgbgb50, pedronis
Priority: low Keywords:

Created on 2000-11-18.18:46:12 by bckfnn, last changed 2006-11-24.21:17:19 by gbgbgb50.

Messages
msg9 (view) Author: Finn Bock (bckfnn) Date: 2000-11-18.18:46:12
According to the Python library documentation, the "id" builtin
function will return unique integers for different objects. The
documentation for java's hashCode makes no such garantee. The new
hotspot VM change the behavior of the JDK and the hashCode (and
identifyHashCode) function can return the same integer for different
objects.

pickle.py assumes that id() returns unique values.


======= From Python docs "__builtin__.id()"=========
Return the `identity' of an object. This is an integer which is
guaranteed to be unique and constant for this object during its
lifetime.

======= From Java docs "Object.hashCode()" =========
As much as is reasonably practical, the hashCode method defined by
class Object does return distinct integers for distinct  objects.
(This is typically implemented by converting the internal address of
the object into an integer, but this implementation technique is not
required by the JavaTM programming language.)


 --------- FILE: test099.py  --------- 

d = {}

for i in xrange(100000):
    s = "test" + `i`
    j = id(s)
    if d.has_key(j):
        print "Duplicate id %s<%d> & %s<%d>" % (s, j, d[j],
id(d[j]))
    d[j] = s

 --------- END  --------- 
msg10 (view) Author: Finn Bock (bckfnn) Date: 2000-11-26.13:07:12
Tim Peters think this should be solved even if it mean that every object should carry some id field around in PyObject. I think we can live with this difference. Since I trust Tim more then I trust myself I keep the bug open for now. See the python-dev archives for the discussion.

http://www.python.org/pipermail/python-dev/2000-June/thread.html#22346
msg11 (view) Author: Charlie Groves (cgroves) Date: 2006-09-07.04:45:34
Logged In: YES 
user_id=1174327

Has anyone ever seen test099.py fail?  Since we haven't seen
an actual bug from this in 6 years, I'm going make this
pending won't fix.
msg12 (view) Author: Samuele Pedroni (pedronis) Date: 2006-09-07.11:12:37
Logged In: YES 
user_id=61408

this was fixed by me using an object->id mapping quite some 
time ago. 
msg13 (view) Author: Samuele Pedroni (pedronis) Date: 2006-09-18.19:58:57
Logged In: YES 
user_id=61408

mark as fixed because it actually was
msg14 (view) Author: gunter bach (gbgbgb50) Date: 2006-11-24.16:29:14
I do get many duplicates (137) when running test099.py!

I came across this bug, when I was trying to debug my own application which yields very strange results when
deep-copying a dictionary many times...
Looks for me like this id()-bug is the reason.

I ran the test099.py on windows jdk1.6.0-beta and on two different debian-boxes, both java version "1.5.0_03".
Ah, and I used the jython2.1-relase.

yours

Gunter

msg15 (view) Author: Samuele Pedroni (pedronis) Date: 2006-11-24.17:49:08
there's careful code to produce unique ids now, indeed is so different that the problem would not be related at all with the original problem. This kind of test still passes without clashes for me with a recent trunk and java 1.5.

Maybe there's something subtle going wrong with more 1.6 beta ?
msg16 (view) Author: gunter bach (gbgbgb50) Date: 2006-11-24.21:17:19
I just checked again with jython 2.2a1 (using windows this time java 1.5.0_06.

Here no duplicate id occures, so I will try to run my app with 2.2a1.

History
Date User Action Args
2000-11-18 18:46:12bckfnncreate