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

Raymond Hettinger raymond.hettinger at gmail.com
Sun Nov 5 21:44:20 EST 2017

> On Nov 5, 2017, at 4:31 PM, Nathaniel Smith <njs at pobox.com> wrote:
> CPython does in practice provide ordering guarantees for dicts, and this solves a whole bunch of pain points: it makes json roundtripping work better, it gives ordered kwargs, it makes it possible for metaclasses to see the order class items were defined, etc. And we got all these goodies for better-than-free: the new dict is faster and uses less memory. So it seems very unlikely that CPython is going to revert this change in the foreseeable future, and that means people will write code that depends on this, and that means in practice reverting it will become impossible due to backcompat and it will be important for other interpreters to implement, regardless of what the language definition says.
> That said, there are real benefits to putting this in the spec. Given that we're not going to get rid of it, we might as well reward the minority of programmers who are conscientious about following the spec by letting them use it too.

Thanks. Your note resonated with me -- the crux of your argument seems to be that the proposal results in a net reduction in complexity for both users and implementers.

That makes sense. Even having read all the PEPs, read all the patches, and having participated in the discussions, I tend to forget where ordering is guaranteed and where it isn't.

This discussion reminds me of when Timsort was introduced many years ago.  Sort stability wasn't guaranteed at first, but it was so darned convenient (and a pain to work around when not present) that it became guaranteed in the following release.   The current proposal is different in many ways, but does share the virtue of being a nice-to-have for users.

> MicroPython deviates from the language spec in lots of ways. Hopefully this won't need to be another one, but it won't be the end of the world if it is.

I've looked at the MicroPython source and think this won't be a problem.  It will be even easier for them than it was for us (the code is simpler because it doesn't have special cases for key-sharing, unicode optimizations, and whatnot).


More information about the Python-Dev mailing list