[Python-Dev] Guarantee ordered dict literals in v3.7? (original) (raw)
Steven D'Aprano steve at pearwood.info
Tue Dec 19 02:09:28 EST 2017
- Previous message (by thread): [Python-Dev] Guarantee ordered dict literals in v3.7?
- Next message (by thread): [Python-Dev] Guarantee ordered dict literals in v3.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] Guarantee ordered dict literals in v3.7?
- Next message (by thread): [Python-Dev] Guarantee ordered dict literals in v3.7?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]