I'm not entirely sure I understand the full set of reasoning for this - I couldn't really tell what the problem with OrderedDict is from the link Stefan provided. It seems to me like a kind of huge change for the language to move from arbitrary-ordered to guaranteed-ordered dict. The problem I see is that this introduces a huge backwards compatibility burden on all implementations of Python.
It's possible that no implementations of Python (either future CPython versions or current/future alternative interpreters) will find any reason to use anything but an insertion-order sorted dictionary, but given that we've done just fine with arbitrary-order semantics for the entire lifetime of the language /and/ there is a container (OrderedDict) which has guaranteed order semantics, it doesn't seem worth it to me. I think I would mostly be concerned with (in terms of likeliness to occur): 1. An edge case we haven't thought of where arbitrary order dictionaries would allow some crticial optimization for a given platform (perhaps in someone writing a transpiler to another language where the convenient equivalent container has arbitrary order, e.g. if Brython wants to implement dicts in terms of objects - https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order ) 2. Someone invents a new arbitrary-ordered container that would improve on the memory and/or CPU performance of the current dict implementation 3. Some sort of bug or vulnerability is discovered that makes insertion-ordered dictionaries an unwise choice (similar to the hash collision vulnerability that necessitated hash randomization - https://stackoverflow.com/questions/14956313#14959001 ). Perhaps these concerns are overblown, but if indeed guaranteed-order Mapping literals are critical in some or many cases, maybe it would be preferable to introduce new syntax for OrderedDict literals. Best, Paul On 11/05/2017 12:50 PM, Guido van Rossum wrote: > Yup. At least such code will not break in 3.5. > > In general if you write code using a newer version you should expect > arbitrary breakage when trying to run it under older versions. There is no > compatibility guarantee in that direction for anything anyways. > > I don't see this as a reason to not put this into the language spec at 3.7. > > On Sun, Nov 5, 2017 at 9:37 AM, Barry Warsaw <ba...@python.org> wrote: > >> On Nov 4, 2017, at 11:35, Guido van Rossum <gu...@python.org> wrote: >>> >>> This sounds reasonable -- I think when we introduced this in 3.6 we were >> worried that other implementations (e.g. Jython) would have a problem with >> this, but AFAIK they've reported back that they can do this just fine. So >> let's just document this as a language guarantee. >> >> The other concern was backward compatibility issues. For example, if 3.7 >> makes this guarantee official, and folks write code with this assumption >> that has to work with older versions of Python, then that code could be >> buggy in previous versions and work in 3.7. This will probably be most >> evident in test suites, and such failures are often mysterious to debug (as >> we’ve seen in the past). >> >> That doesn’t mean we shouldn’t do it, but it does mean we have to be >> careful and explicit to educate users about how to write safe >> multi-Python-version code. >> >> Cheers, >> -Barry >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ >> guido%40python.org >> >> > > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
