A RetroSearch Logo

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

Search Query:

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

[Python-Dev] Pie-thon benchmark code ready

[Python-Dev] Pie-thon benchmark code readySamuele Pedroni pedronis at bluewin.ch
Fri Jan 2 12:37:26 EST 2004
At 09:08 02.01.2004 -0800, Michael Chermside wrote:
>Samuele Pedroni writes:
> > at 0x<identity-hash-code> [is not unique],
> > 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.
>
>Does "0x<hex(id(.))>" also have a performance problem? I seem to recall
>your saying that a bit of work needed to be done to make id() unique,
>and I thought I remembered that this work could be skipped whenever
>id() wasn't used.

yes, OTOH although id() is convenient and often used in Python, a generic 
repr is the only place were it is kind of useful. There are other languages 
that do fine without id() and have only an 'is' operator, and their default 
repr OTOH is lacking because of non-uniquess issues or "addresses" changing 
under someone's nose.

>That's all well and good since id() is not used all
>that much, but __repr__ *WILL* be used all over the place. Of course, it's
>likely my recollections are incorrect.

all over the place yes, but I don't think there are a lot of performance 
critical code
that produces tons of output with default <... at 0x...> reprs in it, 
Guido's benchmark notwithstanding. 


More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4