Luca Barba <alu...@alucab.org> added the comment:
I agree with arjanstaring This implementation is not standard compliant and breaks interoperability with every ECMA compliant Javascript deserializer. Technically is awful of course but interoperability and standardization come before than technical cleanliness IMHO Regarding standardization: If you consider https://tools.ietf.org/html/rfc7159 there is no way to represent the literal "nan" with the grammar supplied in section 6 hence the Infinity and Nan values are forbidden so as "nan" For interoperability If you consider http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf It is clearly stated in section 24.5.2 Note 4 that JSON.stringify produces null for Infinity and NaN "Finite numbers are stringified as if by calling ToString(number). NaN and Infinity regardless of sign are represented as the String null" It is clearly stated in section 24.5.1 that JSON.parse uses eval-like parsing as a reference for decoding. nan is not an allowed keyword at all. For interoperability NaN could be used but out from the JSON standard. So what happens is that this will break all the ECMA compliant parsers (aka browsers) in the world. Which is what is happening to my project by the way Pandas serialization methos (to_json) already adjusts this issue, but I really think the standard should too ---------- nosy: +alucab _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40633> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
