RetroSearch Browse

Thu Jan 1 13:05:12 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-January/041565.html

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.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-January/041565.html below:

[Python-Dev] Pie-thon benchmark code ready