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

[Steven D'Aprano]

On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
> implementation happens to keep that, great. 

That's the worst of both worlds. The status quo is that unless we 
deliberately perturb the dictionary order, developers will come to rely 
on implementation order (because that's what the CPython reference 
implementation actually offers, regardless of what the docs say). 
Consequently:

- people will be writing non-portable code, whether they know it or not;

- CPython won't be able to change the implementation, because it will 
break too much code;

- other implementations will be pressured to match CPython's 
implementation.

The only difference is that on the one hand we are honest and up-front 
about requiring order-preserving dicts, and on the other we still 
require it, but pretend that we don't.

And frankly, it seems rather perverse to intentionally perturb 
dictionary order just to keep our options open that someday there might 
be some algorithm which offers sufficiently better performance but 
doesn't preserve order. Preserving order is useful, desirable, often 
requested functionality, and now that we have it, it would have to be 
one hell of an optimization to justify dropping it again.

(It is like Timsort and stability. How much faster sorting would it 
have taken to justify giving up sort stability? 50% faster? 100%? We 
wouldn't have done it for a 1% speedup.)

It would be better to relax the requirement that builtin dict is used 
for those things that would benefit from improved performance. Is there 
any need for globals() to be the same mapping type as dict? Probably 
not. If somebody comes up with a much more efficient, non-order- 
preserving map ideal for globals, it would be better to change globals 
than dict. In my opinion.


> Maybe OrderedDict can be
> rewritten to use the dict implementation. But the evidence that all
> implementations will always be fine with this restraint feels poor,

I think you have a different definition of "poor" to me :-)

Nick has already done a survey of PyPy (which already has insertion- 
order preserving dicts), Jython, VOC, and Batavia, and they don't have 
any problem with this. IronPython is built on C#, which has order- 
preserving mappings. Nuitka is built on C++, and if C++ can't implement 
an order-preserving mapping, there is something terribly wrong with the 
world. Cython (I believe) uses CPython's implementation, as does 
Stackless.

The only well-known implementation that may have trouble with this is 
MicroPython, but it already changes the functionality of a lot of 
builtins and core language features, e.g. it uses a different method 
resolution order (so multiple inheritence won't work right), some 
builtins don't support slicing with three arguments, etc.

I think the evidence is excellent that other implementations shouldn't 
have a problem with this, unless (like MicroPython) they are targetting 
machines with tiny memory resources. µPy runs on the PyBoard, which I 
believe has under 200K of memory. I think we can all forgive µPy if it 
only *approximately* matches Python semantics.


-- 
Steve