On 12/19/2017 5:32 PM, Nathaniel Smith wrote:
On Tue, Dec 19, 2017 at 4:56 PM, Steve Dower <steve.do...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
