On 11/6/2012 5:12 PM, Guido van Rossum wrote:
On Tue, Nov 6, 2012 at 9:58 AM, Ned Batchelder <n...@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 <storch...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
