[Python-Dev] Guarantee ordered dict literals in v3.7? (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Wed Dec 20 00:15:24 EST 2017

On 12/19/2017 5:32 PM, Nathaniel Smith wrote:

On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower <steve.dower at python.org> wrote:

On 19Dec2017 1004, Chris Barker wrote:

Nathaniel Smith has pointed out that eval(pprint(adict)) is supposed to return the same dict -- so documented behavior may already be broken.

Two relevant quotes from the pprint module docs:

The pprint module provides a capability to “pretty-print” arbitrary Python data structures in a form which can be used as input to the interpreter Dictionaries are sorted by key before the display is computed. It says nothing about the resulting dict being the same as the original one, just that it can be used as input. So these are both still true (until someone deliberately breaks the latter). This is a pretty fine hair to be splitting... I'm sure you wouldn't argue that it would be valid to display the dict {"a": 1} as '["hello"]', just because '["hello"]' is a valid input to the interpreter (that happens to produce a different object than the original one) :-). I think we can assume that pprint's output is supposed to let you reconstruct the original data structures, at least in simple cases, even if that isn't explicitly stated.

Any dict object read in from pprint is going to be a different object, not the original one. And, unless the original insertion order was sorted by the same key as pprint uses to sort, the iteration order will be different from the original.

As pointed out below, it will compare equal to the original dict.

pprint has always allowed you to reconstruct the original data structures, but not the iteration order of dicts.

With the new insertion order guarantee, nothing has changed, here.

A far more interesting question than what pprint does to dict order is what marshal and pickle do (and have done) with the dict order, although I can't figure that out from the documentation.

In any case, there are so many ways to spoil the first point for yourself that it's hardly worth treating as an important constraint. I guess the underlying issue here is partly the question of what the pprint module is for. In my understanding, it's primarily a tool for debugging/introspecting Python programs, and the reason it talks about "valid input to the interpreter" isn't because we want anyone to actually feed the data back into the interpreter, but to emphasize that it provides an accurate what-you-see-is-what's-really-there view into how the interpreter understands a given object. It also emphasizes that this is not intended for display to end users; making the output format be "Python code" suggests that the main intended audience is people who know how to read, well, Python code, and therefore can be expected to care about Python's semantics.

(though I assume order is still ignored when comparing dicts, so: eval(pprint(adict)) == adict will still hold. Order had better be ignored when comparing dicts, or plenty of code will break. For example:

{'a': 1, 'b': 2} == {'b': 2, 'a': 1} True Yes, this is never going to change -- I expect that in the long run, the only semantic difference between dict and OrderedDict will be in their eq methods. Saying that "iter(dict)" will produce keys in the same order as they were inserted is not the same as saying that "dict" is an ordered mapping. As far as I understand, we've only said the first part. (And the "nerve" here is that I disagreed with even the first part, but didn't fight it too strongly because I never relied on the iteration order of dict. However, I do rely on nobody else relying on the iteration order of dict either, and so proposals to change existing semantics that were previously independent of insertion order to make them rely on insertion order will affect me. So now I'm pushing back.) I mean, I don't want to be a jerk about this, and we still need to examine things on a case-by-case basis but... Guido has pronounced that Python dict preserves order. If your code "rel[ies] on nobody else relying on the iteration order", then starting in 3.7 your code is no longer Python. Obviously I like that change more than you, but to some extent it's just something we have to live with, and even if I disagreed with the new semantics I'd still rather the standard library handle them consistently rather than being half-one-thing-and-half-another. -n

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171219/8cd25e94/attachment.html>

More information about the Python-Dev mailing list