On 07/08/2011 10:31 AM William ML Leslie wrote:
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.
python -c 'import this'|egrep 'rules|purity|hard' #;-)
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev