[Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

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 <barry at python.org> wrote:
> 
>> On Nov 4, 2017, at 11:35, Guido van Rossum <guido at 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171105/6b166bac/attachment.sig>