Christian Tanzer <tan...@swing.co.at> 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
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 <rep...@bugs.python.org> wrote:
>
> Andrei Kulakov <andrei....@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 <rep...@bugs.python.org>
> <https://bugs.python.org/issue25457>
> _______________________________________
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25457>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
