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 or lead to problems down the line makes no sense. The user is asking for an object with string keys and they want the keys sorted. That is unambiguous and well defined.

Neither does adding a second argument make any sense, it would just increase the confusion.

My problem was that Python 3.x threw an exception about this for a complex json object in a context where it was not at all obvious what was going on. And the code in question had worked for years in Python 2.

This bug report is many, many years old and I don’t much care one way or another but I am very sad that 

     Practicality beats purity 

got utterly lost in and after the transition to Python 3.

Christian Tanzer

> On 10.07.2021, at 16:12, Andrei Kulakov <report@bugs.python.org> wrote:
> 
> Andrei Kulakov <andrei.avk@gmail.com> 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() < int()' If uncertain, a user can go to interactive shell and try `1 < "2"`, and then the issue is obvious.
> 
> - to me, current behaviour seems preferable to silently guessing that users wants stringified sorting, especially since it can surface as a problem way down the line.
> 
> - what makes this issue interesting is that in roughly half of cases (I'm guessing) the user will want object sorted and then cast to string and would be surprised if the reverse happened, and in the other half cases the user would want them stringified, then sorted, and would be surprised if that didn't happen.
> 
> It depends on the perspective: you may think of the json as a representation of a dict of objects, that just happen to be in json format; or you can think of it as a json document with string keys (of course) that just happen to come from a dict of objects. Both can be valid depending on the use case.
> 
> Given all of this, I propose keeping current behavior for the existing arg, and adding another arg for 'stringify then sort' behavior. Then we'll have no silent guessing and the "unorderable" type error message can point the user directly to the new argument.
> 
> If the user reads the docs before using this method, they will see two clear options with respective tradeoffs and decide which one to use.
> 
> So either by reading the docs or running into the error, the user will have a clear explanation and a clear and convenient solution.
> 
> ----------
> nosy: +andrei.avk
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue25457>
> _______________________________________