17.06.20 08:42, David Mertz пише:
I think the argument 'allow_nan' is poorly spelled. Spelling it 'strict' would have been much better. Maybe 'conformant'. I'm not sure I hate the spelling enough to propose a change with depreciation period, but I certainly wouldn't oppose that.
It is not only thing which which makes Python implementation non-conforming to the standard or incompatible with other implementations. 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. Python implementation uses the above algorithm (with variation). You can also use arbitrary explicit encoding. 3. Python implementation supports integers of arbitrary size. Other implementations can be limited to 32- or 64-bit integers. 4. Python implementation is limited to precision and range of IEEE-754 for non-integer numbers. Other implementations can support larger precision and range. 5. Python implementation supports single surrogate characters in strings. Other implementations can be limited. 6. Python implementation can produce JSON objects with duplicated keys (and their order was unspecified before 3.6), for example when serialize {1: 1, "1": 2}. So there is more than one meaning in the term "strict", and it may be changed with changing the JSON standard.