[Python-Dev] Pie-thon benchmark code ready
Samuele Pedroni
pedronis at bluewin.ch
Thu Jan 1 13:05:12 EST 2004
At 20:44 31.12.2003 -0800, Guido van Rossum wrote:
>But I've seen enough people write code that parses <...> reprs in some
>way to make me think that maybe they should be standardized somewhat,
>at least to the point where different Python implementations should
>not differ gratuitously. E.g. Jython could be much closer to CPython
>by inserting 'at 0x'. It's not like standardizing this would close
>off an important implementation freedom for other Python
>implementation. (I won't go as far as requiring that the number
>should be the same as hex(id(x)). :-)
btw in 2.1 there was no 0x (at least on Windows):
Python 2.1.3 (#35, Apr 8 2002, 17:47:50) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> class C: pass
...
>>> C
<class __main__.C at 007DE55C>
>>>
so in Jython:
Jython 2.1 on java1.3.0 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> class C: pass
...
>>> C
<class __main__.C at 4862296>
(and that number was not in hexadecimal)
In the new world where Jython has a correct unique id:
>>> class C: pass
...
>>> C
<class __main__.C 1>
>>>
1 is id(C) but that's really not an address, so I'm not so keen in putting a
'at 0x' in there because is misleading and confusing cosidering the Java
default repr
for objects:
java.lang.Object at ac7fbb
which uses System.identityHashCode which is not unique, and is what we were
using in Jython 2.1 (without going to hex). If I were to put an 'at 0x' in
there, I would be tempted to revert to that value (System.identityHashCode)
but given that is not unique and != id(.), it is rather less useful.
More information about the Python-Dev
mailing list