[pypy-dev] Object identity and dict strategies

[William ML Leslie]

On 9 July 2011 18:17, Armin Rigo <arigo at tunes.org> wrote:
> 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.
>
>> ...
>
> I don't understand these two sentences, because they seem to say the
> exact opposite of each other...

For a non-smallint integer or float bound to x, "x is x" is
tautological by virtue of x being represented by the same instance.

There may be other objects with the same value, but I don't see why
that must imply that they be the same object - why x == y must imply x
is y for x and y of the same immutable type.  It might make the
identity dict in copy.py use slightly less memory, but it would make
*much* more sense to optimise the specific use case according to the
defined semantics of id(). copy.py is already effectively "broken" by
the behaviour of non-cached ints on cpython; so copy.py is no excuse
to break id() in pypy, which is a much more fundamental concept.

>> 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.

I'm not disagreeing with you there, but id has a *universally* finite
range already, and imao, to change this is to make an annoying change
to the language.

>> 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.

Ok. It would be little help to existing code.

-- 
William Leslie