[pypy-dev] Object identity and dict strategies

Armin Rigo arigo at tunes.org
Sat Jul 9 10:17:33 CEST 2011


Hi,

On Sat, Jul 9, 2011 at 5:20 AM, William ML Leslie
<william.leslie.ttg at gmail.com> wrote:
> My point about small integers (...)

I think that your point about small integers is broken (even assuming
that smallints are enabled by default, which is not the case).  It
means that we'd get an id() function which "behaves" as long as taking
the id() of a 31-bit signed integer, and then doesn't behave as
expected neither for full 32-bit integers, nor for longs, nor for
floats.

> This happens to work for larger integers and floats, because the id
> will be preserved as long as a reference to them exists by their
> boxedness.
> Floats could use a similar mechanism to integers, eg, their bit
> representation shifted left two and bitwise-ored with 2.

I don't understand these two sentences, because they seem to say the
exact opposite of each other...

> That does mean that id() is no longer word-sized, but it does not make it
> unbounded.

The "unbounded" part in my e-mail was about longs.  Obviously if you
are computing id(x) where x is in some finite set (like ints or
floats), then the results are in some finite set too.

> What is keeping us from using the underlying rpython string as the
> basis for id?

This is probably a good enough workaround for strings and unicodes.

> Speaking of, maybe it'd be easier to attempt to get the identity dict
> into the language proper.

We tried at some point, but python-dev refused the idea.  Maybe the
idea has more chances for approval now that we can really show with
performance numbers that it's a deep issue, as opposed to just wave
our hands.  Feel free to try again.  In the meantime I've decided, at
least myself, to stick with the approach that Python is whatever is in
2.7, and that we have to work around such issues instead of fixing
them properly in the language.


A bientôt,

Armin.


More information about the pypy-dev mailing list