Message253368
Josh Rosenberg wrote at Fri, 23 Oct 2015 02:45:51 +0000:
> The Python 2 sort order is a result of the "arbitrary but consistent
> fallback comparison" (omitting details, it's comparing the names of
> the types), thus the "strange" sort order.
Thanks. I knew that.
> Python 3 (justifiably) said that incomparable types should be
> incomparable rather than silently behaving in non-intuitive ways,
> hiding errors.
"justifiably" is debatable. I consider the change ill-conveived.
Displaying a dictionary (or just its keys) in a readable, or just
reproducible, way is useful in many contexts. Python 3 broke that for
very little, INMNSHO, gain.
I consider "hiding errors" a myth, to say it politely!
> Python is being rather generous by allowing non-string keys, because
> the JSON spec ( http://json.org/ ) only allows the keys ("names" in
> JSON parlance) to be strings. So you're already a bit in the weeds as
> far as compliant JSON goes if you have non-string keys.
There are two possibilities:
1) Accepting non-string keys is intended. Then `sort_keys` shouldn't
break like it does.
As far as JSON goes, the output of `json.dump[s]` contains string keys.
2) Accepting non-string keys is a bug. Then `json.dump[s]` should be
changed to not accept them.
Mixing both approaches is the worst of all worlds.
> Since mixed type keys lack meaningful sort order, I'm not sure it's
> wrong to reject attempts to sort them.
The documentation says:
If sort_keys is True (default False), then the output of dictionaries
will be sorted by key; this is useful for regression tests to ensure
that JSON serializations can be compared on a day-to-day basis.
**Reproducible** is the keyword here.
**Readability** is another one. Even if the sort order is "strange",
it is much better than random order, if you are looking for a specific
key.
For the record, it was a test failing under Python 3.5 that triggered
this bug report.
> > As all they keys are dumped as strings, a simple solution would be to
> > sort after converting to strings.
> Converting to string is as
> arbitrary and full of potential for silently incorrect comparisons as
> the Python 2 behavior, and reintroducing it seems like a bad idea.
json.dumps already does the conversion::
>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"})
'{"foo": "bar", "1": 42, "null": "nada"}'
Another run::
>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"})
'{"1": 42, "foo": "bar", "null": "nada"}'
That difference is exactly the reason for `sort_keys`. |
|
Date |
User |
Action |
Args |
2015-10-23 08:09:53 | tanzer@swing.co.at | set | recipients:
+ tanzer@swing.co.at, josh.r |
2015-10-23 08:09:53 | tanzer@swing.co.at | link | issue25457 messages |
2015-10-23 08:09:52 | tanzer@swing.co.at | create | |
|