On 6/27/20 8:51 AM, Serhiy Storchaka wrote: > 27.06.20 10:23, Steven D'Aprano пише: >> On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote: >>> Adding NANs and INFs to JSON will break virtually every software which >>> reads JSON because many (most?) of existing standard-conforming >>> implementations do not support them. >> >> It won't break anything that doesn't actually include NANs or INFs. > > If it does not include NANs or INFs you do need the ability to > serialize them. > >> I don't know anyone who likes the fact that JSON cannot round-trip all >> Javascript numbers. Its a source of pain to anyone who deals with such >> numbers where infinities and NANs might appear. JSON has changed in the >> past, breaking backwards compatibility, and I dare say it will change >> again in the future. Why is it unthinkable for this issue? > > Javascript numbers are unrelated to Python. Python floats include NaNs > and infinities, and it may be a problem if they are occurred in a > serialized data. But Python has a non-standard extension (enabled by > default for historical reasons) to solve this problem. It is important > to understand that it is a non-standard extension, and the result may > be not compatible with other JSON implementations. > > Maybe future JSON standards will support NaNs and infinities, and > other things. But this is not our business. The json module just > implements the current standard, and supports compatibility with past > implementations.
Another way to look at this is that currently, the JSON standard doesn't handle some values (like NAN and INF) that a Python program might try to send to a JSON. The JSON encoder has a couple of choices of what to do: 1) (The Current) Use an 'extension' to the JSON standard to output the value in a way that JSON dosn't strictly allow. 2) It could quietly accept the value, and output some legal value, making the JSON not round trip, and perhaps be considered 'lying' on the output. This could be something like output the maximum real value for infinity (or even a number bigger so it might actually come back as infinity). NAN might be harder to think of a reasonable value, some might use 0 or -9999. 3) It could complain (loudly our quietly) about the bad value, and if it quietly complained, it might generate an output based on one of the previous methods. Quietly would be returning an error code, loudly would be throwing an exception. Depending on the actual application, any of these could be the 'right' choice. Fundamentally, we end up back at the maxim of being generous of what we accept, and rigorous in what we generate, but run into the quandary of if we accept a value that JSON can't handle, what is the right trade off of being generous and rigorous (we CAN'T be totally both) -- Richard Damon _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@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/HGS53FAGOS4Z3VKBLO7PW2HT2TTLPGAM/ Code of Conduct: http://python.org/psf/codeofconduct/
