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:
>>
>> 1) 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 :-)
>>
>> 2) 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/JSG3EKNSCWUHAUOHUMQSEMKMV2JTXWAH/
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