On Wed, Jun 17, 2020 at 09:18:00AM +0300, Serhiy Storchaka wrote:
17.06.20 08:29, Steven D'Aprano пише:
What exactly is getting in the way here? Standards do change. One standard (JSON) is not capable of representing all values from another standard (IEEE-754). Removing NANs and INFs would break floating point software everywhere, and a lot of hardware too. Adding support for them to JSON would be an enhancement, not a breakage. In my ignorance, that seems like a no-brainer.
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. In another post, you replied to David Mertz: "1. Initial standard allowed only JSON objects and JSON arrays at the top level, but Python implementations allowed all. Now the standard has been changed." "2. Initial standard allowed binary input and suggested algorithm to determine the encoding (if it one of UTF-8, UTF-16, UTF-32 with variations). Current standard requires UTF-8 encoding." So the standard has changed in the past. Breakage can be managed. 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? There might be a good reason. But it's not obvious to me what that would be, other than "But we've always done it this way". -- Steven