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

[Glenn Linderman]

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(a_dict)) 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(a_dict)) == a_dict 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>