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.


On Sun, Aug 11, 2019 at 10:05 PM Chris Angelico <> wrote:
On Mon, Aug 12, 2019 at 3:01 PM Christopher Barker <> wrote:
> On Sun, Aug 11, 2019 at 5:12 PM David Shawley <> 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.

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython