On 8 July 2011 17:58, holger krekel <hol...@merlinux.eu> wrote:
> IOW, i think the issue here is that iterating over keys of a dict usually
> gives the exact same ("is") objects in CPython whereas pypy trunk does not
> provide that at least for ints.I couldn't find anything precise in the official documentation on the meaning of 'is'. I think that the general understanding is that it makes no sense whatsoever on immutable objects (as in, it isn't guaranteed to do so). Consequently, a python implementation could also cache tuples. Re-using tuples might sound unusual, but there are special cases that start to sound reasonable, such as caching the empty tuple, or copy-propogating a tuple unpack & repack. The language spec is very light on what is allowed to be a 'different object', and what is *suggested* by cpython's int caching behaviour is that the behaviour of 'is' for language-provided immutable objects can't be relied upon in any way, shape or form. Pypy hasn't matched cpython's behaviour with ints here in a long time, so it obviously doesn't matter. On another note: what Alex talks about as being two different cases are just one with the small int optimisation - all references can be compared by value in the C backend with small ints enabled, if the object space doesn't provide alternative behaviour. -- William Leslie _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev
