Another doc note:
I see this:
""" it is common for JSON numbers to be deserialized into IEEE 754 double precision numbers and thus subject to that representation’s range and precision limitations. This is especially relevant when serializing Python int values of extremely large magnitude, or when serializing instances of “exotic” numerical types such as decimal.Decimal. """
This is a bit ironic, as apparently it is actually impossible with the current implementation to serialize a Decimal with many digits into JSON anyway.
Perhaps a doc patch with some clarifications will be in order once the question at hand is resolved.
-CHB
On Mon, Aug 12, 2019 at 2:06 PM Christopher Barker pythonchb@gmail.com wrote:
side note:
I"m reading teh json docs more closely now, and noticed:
""" parse_float, if specified, will be called with the string of every JSON float to be decoded. By default, this is equivalent to float(num_str). This can be used to use another datatype or parser for JSON floats (e.g. decimal.Decimal)." """
it's unfortunate that he term "JSON float" is used here when it should really be something like "JSON number with a fractional part" or "JOSN non- integer number", since the JSON spec is not the same as a C or Python float. Not sure it's worth the doc edit, but it explains we there was some confusion in terminology at the beginning of this thread.
-CHB
On Sun, Aug 11, 2019 at 10:05 PM Chris Angelico rosuav@gmail.com wrote:
On Mon, Aug 12, 2019 at 3:01 PM Christopher Barker pythonchb@gmail.com wrote:
On Sun, Aug 11, 2019 at 5:12 PM David Shawley daveshawley@gmail.com
wrote:
- Should JSONEncoder (the class underlying json.dumps) natively
support decimal.Decimal, and if so, can it avoid importing that module unnecessarily?
I think yes on both counts :-)
- Should there be a protocol obj.__json__() to return a string
representation of an object for direct insertion into a JSON file?
I'm inclined towards the protocol, since there are protocols for various other encoders (eg deepcopy, pickle), and it avoids the problem of json importing decimal. It can also be implemented entirely as a third-party patch, although you'd need to subclass Decimal to add that method.
I think if we ARE going to extend json to allow more flexibility, yes,
a protocol would be a good way to do it.
But it makes me nervous -- I think the goal of the json module is to
produce valid json, and nothing else. Opening up a protocol would allow users to fairly easily, and maybe inadvertently, create invalid JSON. I'm not sure there are compelling use cases that make that worth it.
You can already make invalid JSON, and far more easily.
json.dumps({"spam": [1,2,3]}, separators=(' : ',', '))
'{"spam", [1 : 2 : 3]}'
It's not the module's job to stop you from shooting yourself in the foot.
ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JSG3EK... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython