On Aug 14, 2019, at 09:22, Random832 <random...@fastmail.com> wrote: > >> On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote: >> class float: >> def __json__(self): >> if math.isfinite(self): return str(self) >> return "null" > > Er, to be clear, the current JSON decoder returns 'Infinity', '-Infinity', or > 'NaN', which are invalid JSON, not null. This behavior (vs raising an > exception) is governed by a flag.
But that’s a special case, as already discussed on this thread. Those values are invalid JSON according to the RFC. But, for historical reasons, passing around these three values used to be near-ubiquitous, and they’re still pretty common even 6 years after the ECMA spec and RFC definitely said they’re illegal. So, a library that refuses to cooperate with that won’t interoperate properly with zillions of existing services and programs, and which side is the user going to blame? > I'm mainly bringing this up to point out that the concerns about a raw > protocol being able to generate invalid JSON seem somewhat overblown and that > "people should be able to generate invalid JSON if they want to" is not > without precedent. Sure, and as soon as you discover another special case that millions of existing programs expect to be handled in a way that violates the RFC, that somehow nobody has noticed in the last 16 years, file a bug to handle that with another special flag. ;) _______________________________________________ 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/CZCCUYN5AXTMG36HNI5YYHNVI4MVAPMQ/ Code of Conduct: http://python.org/psf/codeofconduct/
