[Python-Dev] chained assignment weirdity

[Guido van Rossum]

On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> 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)