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

David Mertz mertz at gnosis.cx
Tue Nov 7 10:21:21 EST 2017


On Nov 6, 2017 9:11 PM, "Raymond Hettinger" <raymond.hettinger at gmail.com>
wrote:

> On Nov 6, 2017, at 8:05 PM, David Mertz <mertz at gnosis.cx> wrote:
> I strongly opposed adding an ordered guarantee to regular dicts. If the
implementation happens to keep that, great. 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, and we
have a perfectly good explicit OrderedDict for those who want that.

I think this post is dismissive of the value that users would get from
having reliable ordering by default.


Dismissive seems like an overly strong word. I recognize I disagree with
Raymond on best official semantics. Someone else points out that if someday
an "even more efficient unordered dict" is discovered, user-facing "dict"
doesn't strictly have to be the same data structure as "internal dict". The
fact they are is admittedly an implementation detail also.

I've had all those same uses about round-tripping serialization that
Raymond mentions. I know the standard work arounds (which are not
difficult, but DO require a little extra code if we don't have order).

But like Raymond, I make most of my living TEACHING Python. I feel like the
extra order guarantee would make teaching slightly harder. I'm sure he
feels contrarily. It is true that with 3.6 I can no longer show an example
where the dict display is oddly changed when printed. But then, unordered
sets also wind up sorting small integers on printing, even though that's
not a guarantee.

Ordering by insertion order (possibly "only until first deletion") is
simply not obvious to beginners. If we had, hypothetically, a dict that
"always alphabetized keys" that would be more intuitive to them, for
example. Insertion order feels obvious to us experts, but it really is an
extra cognitive burden to learners beyond understanding "key/Val
association".

Having worked with Python 3.6 for a while, it is repeatedly delightful to
encounter the effects of ordering.  When debugging, it is a pleasure to be
able to easily see what has changed in a dictionary.  When creating XML, it
is joy to see the attribs show in the same order you added them.  When
reading a configuration, modifying it, and writing it back out, it is a
godsend to have it written out in about the same order you originally typed
it in.  The same applies to reading and writing JSON.  When adding a VIA
header in a HTTP proxy, it is nice to not permute the order of the other
headers. When generating url query strings for REST APIs, it is nice have
the parameter order match documented examples.

We've lived without order for so long that it seems that some of us now
think data scrambling is a virtue.  But it isn't.  Scrambled data is the
opposite of human friendly.


Raymond


P.S. Especially during debugging, it is often inconvenient, difficult, or
impossible to bring in an OrderedDict after the fact or to inject one into
third-party code that is returning regular dicts.  Just because we have
OrderedDict in collections doesn't mean that we always get to take
advantage of it.  Plain dicts get served to us whether we want them or not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/a39b759d/attachment.html>


More information about the Python-Dev mailing list