On 9 July 2011 18:17, Armin Rigo <ar...@tunes.org> wrote: > Hi, > > On Sat, Jul 9, 2011 at 5:20 AM, William ML Leslie > <william.leslie....@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 _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
