[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 raised in such cases is especially unhelpful. Running
the following:
json.dumps({3:1, 'foo':'bar'}, sort_keys=True)
produces a stack trace that terminates in a function defined in C, with this
error:
TypeError: '<' not supported between instances of 'str' and 'int'
That error doesn't give non-experts very much to go on...!
The fix is reasonably simple: coerce dict keys to strings *before* trying to
sort the keys, not after. The only fuss in making such a patch is that the
behavior has to be fixed in both _json.c and in json/encode.py.
The only other consistent behavior would be to disallow non-string keys, but
that behavior is at this point very well entrenched. So it only makes sense
that encoding should be patched to not fail in corner cases.
--
nosy: +zachrahan
versions: +Python 3.7 -Python 3.5
___
Python tracker
<http://bugs.python.org/issue25457>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 dict was created in that order. Certainly for regression testing, sort_keys is no longer needed, but that's not the only reason people are using that option. (It's certainly not why I use the option -- my use stems from sort_keys improving human readability of the JSON.) But outside of deprecating sort_keys wholesale, it is still a bug that sort_keys=True can cause an error on input that would otherwise be valid for json.dump[s]. -- ___ Python tracker <https://bugs.python.org/issue25457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29298] argparse fails with required subparsers, un-named dest, and empty argv
New submission from zachrahan:
In python 3.6 (and several versions back), using argparse with required
subparsers will cause an unhelpful TypeError if the 'dest' parameter is not
explicitly specified, and no arguments are provided.
Test case:
import argparse
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers()
subparsers.required = True
args = parser.parse_args([])
Observed result:
TypeError: sequence item 0: expected str instance, NoneType found
If the line above is changed to:
subparsers = parser.add_subparsers(dest='function')
Then the following is printed to stderr:
usage: python [-h] {} ...
python: error: the following arguments are required: function
This issue goes back at least several years:
http://stackoverflow.com/questions/23349349/argparse-with-required-subparser/23354355
Though it seems odd to not specify a dest in the add_subparsers line, the
pattern is not completely useless. The below works fine without setting a
'dest' in add_subparsers, except when argv is empty:
sub1 = subparsers.add_parser('print')
sub1.set_defaults(function=print)
However, an empty argv produces the unexpected TypeError above. I'm not sure if
argparse should provide a more useful exception in this case, or if there is a
clean way to do the right thing without a dest specified.
--
components: Library (Lib)
messages: 285646
nosy: zachrahan
priority: normal
severity: normal
status: open
title: argparse fails with required subparsers, un-named dest, and empty argv
type: behavior
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue29298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
