Supporting customization of float encoding in JSON

[mitar]

BPO	36841
Nosy	@rhettinger, @mdickinson, @ezio-melotti, @merwok, @mitar, @minrk, @Lee-W
PRs	gh-81022: Supporting customization of float encoding in JSON #13233 bpo-36841: JSONEncoder call self.default for unsupported floats #28648

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-05-07.20:32:33.357>
labels = ['type-feature', 'library', '3.11']
title = 'Supporting customization of float encoding in JSON'
updated_at = <Date 2021-09-30.12:47:51.360>
user = 'https://github.com/mitar'

bugs.python.org fields:

activity = <Date 2021-09-30.12:47:51.360>
actor = 'mark.dickinson'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-05-07.20:32:33.357>
creator = 'mitar'
dependencies = []
files = []
hgrepos = []
issue_num = 36841
keywords = ['patch']
message_count = 6.0
messages = ['341817', '341904', '341914', '342350', '393441', '402950']
nosy_count = 7.0
nosy_names = ['rhettinger', 'mark.dickinson', 'ezio.melotti', 'eric.araujo', 'mitar', 'minrk', 'clleew']
pr_nums = ['13233', '28648']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue36841'
versions = ['Python 3.11']

[mitar]

Currently, there is only one argument which allows customization how float numbers are encoded in JSON: allow_nan. But this does not allow one to hook into the encoding of floating points really. The JSONEncoder is not called for float numbers.

The motivation here is that we would like to encode NaN and Infinity values differently, instead of non-standard approach and instead of raising an exception.

The "load" counterpart has "parse_float" which one can use to hook into parsing floats. I would suggest something similar, maybe "encode_float" which if provided would be used instead of the default.

[Lee-W]

If no one is working on it, I'd like to give it a try.

[mitar]

That would be awesome!

BTW, just as an additional example, JavaScrpt's JSON.stringify encodes NaN and Infinity to null. By having a custom function I could for example try to match such implementation.

[Lee-W]

I've sent a PR for it.
#13233

[merwok]

I think this should be discussed on the mailing list or Discourse, to get use cases and needs.

[minrk]

We just ran into this in Jupyter where we've removed a pre-processing step for data structures passed to json.dumps, which took care of this, but was expensive jupyter/jupyter_client#706

My expectation was that our default would be called for the unsupported value, but it isn't. I see the PR proposes a new option, but would it be sensible to use the already-existing default callback for this? It seems like what default is for.