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

[Steven D'Aprano]

On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote:

> That means our choices for 3.7 boil down to:
> 
> * make this a language level guarantee that Python devs can reasonably rely on
> * deliberately perturb dict iteration in CPython the same way the
> default Go runtime does [1]

I agree with this choice.

My preference is for the first: having dicts be unordered has never been 
a positive virtue in itself, but always the cost we paid for fast O(1) 
access. Now what we have fast O(1) access *without* dicts being 
unordered, we should make it a language guarantee.

Provided of course that we can be reasonable certain that other 
implementations can do the same. And it looks like we can.

But if we wanted to still keep our options open, how about weakening the 
requirement that globals() and object __dicts__ be specifically the same 
type as builtin dict? That way if we discover a super-fast and compact 
dict implementation (maybe one that allows only string keys?) that is 
unordered, we can use it for object namespaces without affecting the 
builtin dict.


> When we did the "insertion ordered hash map" availability review, the
> main implementations we were checking on behalf of were Jython & VOC
> (JVM implementations), Batavia (JavaScript implementation), and
> MicroPython (C implementation). Adding IronPython (C# implementation)
> to the mix gives:

Shouldn't we check with Nuitka (C++) and Cython as well?

I'd be surprised if this is a problem for either of them, but we should 
ask.


> Since the round-trip behaviour that comes from guaranteed order
> preservation is genuinely useful, and we're comfortable with folks
> switching to more specialised containers when they need different
> performance characteristics from what the builtins provide, elevating
> insertion order preservation to a language level requirements makes
> sense.

+1


OrderedDict could then become a thin wrapper around regular dicts.

-- 
Steve