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

[Steven D'Aprano]

On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote:
> On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
> 
> > > With arbitrary order, it made sense to sort, so as to always give the
> > same
> > > "pretty" representation. But now that order is "part of" the dict itself,
> > > it seems prettyprint should present the preserved order of the dict.
> >
> > I disagree. Many uses of dicts are still conceptually unordered, even if
> > the dict now preserves insertion order. For those use-cases, insertion
> > order is of no interest whatsoever, and sorting is still "prettier".
> >
> 
> and many uses of dicts have "sorted" order as completely irrelevant, and
> sorting them arbitrarily is not necessarily pretty (you can't provide a
> sort key can you? -- so yes, it's arbitrary)

I completely agree. We might argue that it was a mistake to sort dicts 
in the first place, or at least a mistake to *always* sort them without 
allowing the caller to provide a sort key. But what's done is done: the 
fact that dicts are sorted by pprint is not merely an implementation 
detail, but a documented behaviour.


> I'm not necessarily saying we should break things, but I won't agree that
> pprint sorting dicts is the "right" interface for what is actually an
> order-preserving mapping.

If sorting dicts was the "right" behaviour in Python 3.4, it remains the 
right behaviour -- at least for use-cases that don't care about 
insertion order. Anyone using pprint on dicts *now* doesn't care about 
insertion order. If they did, they would be using OrderedDict.

That will change in the future, but even in the future there are lots of 
use-cases for dicts where insertion order might as well be random. The 
order that some dict happen to be constructed may not be "pretty" or 
significant or even consistent from one dict to the next.

(If your key/values pairs are coming in from an external source, they 
might not always come in the same order.)

I'm not denying that sometimes it would be nice to see dicts in 
insertion order. Right now, those use-cases are handled by OrderedDict 
but in the future many of them will be taken over by regular dicts. So 
we have a conflict:

- for some use-cases, insertion order is the "right" way for pprint
  to display the dict;

- but for others, sorting by keys is the "pretty" way for pprint to
  display the dict;

- and there's no way for pprint to know which is which just by 
  inspecting the dict.

How to break this tie? Backwards compatibility trumps all. If we want 
to change the default behaviour of pprint, we need to go through a 
deprecation period.

Or add a flag sorted=True, and let the caller decide.


> I would think it was only the right choice in the first place in order (get
> it?) to get a consistent representation, not because sorting was a good
> thing per se.

*shrug* That's arguable. As you said yourself, dicts were sorted by key 
to give a "pretty" representation. I'm not so sure that consistency is 
the justification. What does that even mean? If you print the same dict 
twice, with no modifications, it will print the same whether you sort 
first or not. If you print two different dicts, who is to say that they 
were constructed in the same order?

But the point is moot: whatever the justification, the fact that pprint 
sorts dicts by key is the defined behaviour, and even if it was a 
mistake to guarantee it, we can't just change it without a deprecation 
period.


-- 
Steve