[Python-Dev] chained assignment weirdity

[Ned Batchelder]

On 11/6/2012 5:12 PM, Guido van Rossum wrote:
> On Tue, Nov 6, 2012 at 9:58 AM, Ned Batchelder <ned at nedbatchelder.com> wrote:
>> On 11/6/2012 11:26 AM, R. David Murray wrote:
>>> On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka <storchaka at gmail.com>
>>> wrote:
>>>> Another counterintuitive (and possible wrong) example:
>>>>
>>>>      >>> {print('foo'): print('bar')}
>>>>      bar
>>>>      foo
>>>>      {None: None}
>>> http://bugs.python.org/issue11205
>>
>> This seems to me better left undefined, since there's hardly ever a need to
>> know the precise evaluation sequence between keys and values, and retaining
>> some amount of "unspecified" to allow for implementation flexibility is a
>> good thing.
> Maybe. Do note that Python tries to be *different* than your average
> C++ standard and actually prescribes evaluation orders in most cases.
> The idea being that the kind of optimizations that C++ compilers get
> to do by moving evaluation order around aren't worth it in Python
> anyway, and it's better for the user if there are no arbitrary
> differences in this area between Python implementations. Note that I
> didn't say "no surprises" -- the post that started this thread shows
> that surprises are still possible.
>

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.

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.

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.  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.

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).  The simplest 
change to make here is to update the reference and keep the implementation.

--Ned.