On 07/08/2011 10:31 AM William ML Leslie wrote:
On 8 July 2011 17:58, holger krekel<[email protected]> 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 [email protected] http://mail.python.org/mailman/listinfo/pypy-dev
