[Python-Dev] Pie-thon benchmark code ready

[Samuele Pedroni]

> > At 14:52 01.01.2004 -0500, Tim Peters wrote:
> > >IOW, CPython is enduring some pain to try to make this consistent too; 
> it's
> > >not only Jython that can't get a free ride here.
>
>[Samuele]
> > is not about having a free ride, it's just that printing the id(.)
> > in Jython as a 'at 0x<hex-something>' is misleading because id(.)
> > now is different from System.identityHashCode which is what goes
> > into the java cls@<identity-hash-code> repr.
>
>I don't care either way.  The importance of having *some* number here
>is that for ordinary objects, if you print two different ones, the
>repr() will show you that they are different, and if you print the
>same one twice, repr() will show that too.  I don't recall ever having
>taken the id() of an object or the address from a repr() and looked it
>up in memory using a debugger.
>
>OTOH if there's a way to get the Java runtime to print things like
><obj>@<addr> it might make sense to get Python's runtime to print the
>same number after 'at'; in general giving developers a warm fuzzy
>feeling of comfort through familiarity is good if it doesn't interfere
>with other goals.

yes, <addr> which is really <identity-hash-code> has that on its side but

 >>> import java.lang.System
 >>> _ihc = java.lang.System.identityHashCode
 >>> class C:
...  def __repr__(self): return "<C obj at 0x%x>" % _ihc(self)
...
 >>> c=C()
 >>> c
<C obj at 0x93a985>
 >>> d={}
 >>> for i in range(10000):
...   new_c = C()
...   ihc = _ihc(new_c)
...   if d.has_key(ihc):
...     print "clash"
...     c = d[ihc]
...     break
...   else:
...    d[ihc] = new_c
...
clash
 >>> java.lang.Object.toString(c)
'org.python.core.PyInstance at e07d3e'
 >>> java.lang.Object.toString(new_c)
'org.python.core.PyInstance at e07d3e'
 >>> c
<C obj at 0xe07d3e>
 >>> new_c
<C obj at 0xe07d3e>
 >>> c is new_c
0

if we standardize on 'at 0x', then

at 0x<identity-hash-code> has the above problem,
at 0x<hex(id(.))> suggests to much the what comes after the 0x is the same 
as what come after @ in the Java repr, which not being the case would be 
confusing.