[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Christian Tanzer added the comment: Json keys *are strings*. That‘s why json.dump stringifies all keys. If you want to argue that this behavior is wrong I wouldn’t protest except for that it breaks extant code. But arguing that sorting the stringified keys would violate user’s expectations

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Andrei Kulakov added the comment: Some observations: - sort_keys arg does a deep sorting of nested dictionaries. It's a bit too much to ask users to do this type of preprocessing manually before dumping to json. - the error doesn't seem too onerous to me. 'unorderable types: str() <

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

naught101 added the comment: I want to do something like this: hashlib.md5(json.dumps(d, sort_keys=True)) So I can check if a dict's contents are the same as a DB version, but I can't guarantee that all the keys are strings, so it breaks, annoyingly. I would very much like the

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Change by Roundup Robot : -- pull_requests: +15382 pull_request: https://github.com/python/cpython/pull/15691 ___ Python tracker ___

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Change by James Edwards : -- keywords: +patch pull_requests: +7617 stage: -> patch review ___ Python tracker ___ ___

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

James Edwards added the comment: This came up in a StackOverflow question[1] today, so I took a stab at addressing the error. The changes don't restore the 2.x behavior, but just do as R. David Murray suggested and coerce the keys to strings prior to sorting to prevent the error. The

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

R. David Murray added the comment: json keys *are* strings, so the fact that we support other object types as keys and coerce them to strings is an "extra feature" of python, and is actually a somewhat questionable feature. The reproducible use case is solved by the

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Aaron Hall added the comment: >From a design standpoint, I'm fairly certain the sort_keys argument was >created due to Python's dicts being arbitrarily ordered. Coercing to strings before sorting is unsatisfactory because, e.g. numbers sort lexicographically instead of

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

R. David Murray added the comment: I'm fairly certain (though not 100%, obviously :) that coercing first and then sorting would be accepted if someone wants to create a PR for this. -- nosy: +r.david.murray versions: +Python 3.8

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Christian Tanzer added the comment: Aaron Hall wrote at Sun, 20 May 2018 16:49:06 +: > Now that dicts are sortable, does that make the sort_keys argument redundant? > > Should this bug be changed to "won't fix"? https://bugs.python.org/issue25457#msg317216 is as good

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

zachrahan added the comment: Well, "wontfix" would be appropriate in the context of deprecating the sort_keys option (over the course of however many releases) and documenting that the new procedure for getting JSON output in a specific order is to ensure that the input

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Aaron Hall added the comment: Now that dicts are sortable, does that make the sort_keys argument redundant? Should this bug be changed to "won't fix"? -- nosy: +Aaron Hall ___ Python tracker

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

zachrahan added the comment: This one just bit me too. It seems that if JSON serialization accepts non-string dict keys, it should make sure to accept them in all circumstances. Currently, there is an error *only* with mixed-type dicts, *only* when sort_keys=True. In addition, the error

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Christian Tanzer added the comment: Josh Rosenberg wrote at Fri, 23 Oct 2015 02:45:51 +: > 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

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Christian Tanzer added the comment: Josh Rosenberg wrote at Fri, 23 Oct 2015 02:56:30 +: > As a workaround (should you absolutely need to sort keys by some > arbitrary criteria), you can initialize a collections.OrderedDict from > the sorted items of your original dict (using whatever key

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

New submission from Christian Tanzer: In Python 3, trying to json-dump a dict with keys of different types fails with a TypeError when sort_keys is specified: python2.7 === Python 2.7.10 (default, May 29 2015, 10:02:30) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Josh Rosenberg added the comment: As a workaround (should you absolutely need to sort keys by some arbitrary criteria), you can initialize a collections.OrderedDict from the sorted items of your original dict (using whatever key function you like), then dump without using sort_keys=True. For

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Josh Rosenberg added the comment: 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. Python 3 (justifiably) said that incomparable types should be incomparable

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

Josh Rosenberg added the comment: Oops, minor flaw with that. It's str-ifying the tuples, not the keys, which could (in some cases) cause issues with keys whose reprs have different quoting. So you'd end up with lambdas. Boo. Anyway, corrected version (which would probably not be one-lined in