Christian Tanzer added the comment: 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`. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25457> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
