On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder
I think it's unfortunate that the current patch in the referenced bug ( http://bugs.python.org/issue11205 ) fixes the "problem" by adding one more bytecode to the compiled Python. The other alternative seems to be changing the meaning of two opcodes. Neither of these are great alternatives. I know we don't promise to maintain backward compatibility in the meanings of opcodes, but I'll bet actual code will be broken by changing the meaning of STORE_MAP and MAP_ADD. Slowing down dict displays (just slightly) to get this right seems unfortunate also.
I agree this would be unfortunate and I recommend that you add this to the bug. I agree that we should be *very* conservative in changing the meaning of existing opcodes (adding new one is a different story). But it was fixed before (http://bugs.python.org/issue448679 has a simple fix that doesn't change opcode meanings and was applied in 2001) -- what happened?
If the bug report is accurate, CPython and the reference manual have disagreed since Python 2.5, and many of us are now surprised to hear it, which means there can't have been much broken code.
Give that it was discussed before and fixed before, I think the intent is clear: we should fix the code, not the docs.
I understand the point about C compilers having more opportunities to take advantage of "undefined" in the spec, but Python implementations are getting cleverer about how to implement Python semantics as well, perhaps we should have some faith in their future cleverness and give them even a little bit of leeway.
Hm. I really don't think that is a good development for Python to compromise in the area of expression evaluation order where side effects are involved. A good compiler should be able to detect the absence of potential side effects. E.g. it might reorder when only constants and simple variable references are present, or (in the case of a JIT, which has run-time type information) when it knows enough about the types of the operands involved to determine that operations like getattr or getitem are guaranteed side-effect-free.
I don't imagine this little bit will actually be useful to them, but making this undefined will already help CPython by avoiding either an extra bytecode or a change in the opcodes.
I haven't looked at the proposed fixes, but I think correctness is more important than saving an extra bytecode (OTOH keeping the set of opcodes the same trumps both). I can't imagine that this extra opcode will be significant in many cases.
There are plenty of places where different Python implementations differ, and even careful observers had different ideas about how keys and values were ordered in dict displays ("I thought it was like a function call," vs, "I thought it was like an assignment"). We've gone out of our way to maintain backward compatibility with the implemented behavior before (ordering of dict keys, for example).
Not sure what you're referencing here -- didn't we just start randomizing hashing?
The simplest change to make here is to update the reference and keep the implementation.
In this particular case I disagree. -- --Guido van Rossum (python.org/~guido)