Can we have some discussion on this topic? Has this pull request some options of being merged?

It's unlikely to get merged, just because simplejson already has too many options, and this has never been requested before. I do otherwise think it is a nice approach to the problem.

Thanks for your explanation.

Two of the five open pull requests are about serializing valid standard JSON. I think that following the standard definition was a requirement, anyway.

Thanks you a lot again for your great work on the library. Perhaps we will fork it to add this option, but the library is pretty good.

Regards,

Just for the record, I published the fork as validjson in pypi, in case someone is interested.

https://pypi.python.org/pypi/validjson

If you're going to do that, I would probably recommend that the default be to throw an exception (allow_nan=False) or encode those values with null like JavaScript does.

> JSON.stringify([+'Infinity', +'NaN'])
"[null,null]"

Yes, outputting null does the job of generating valid JSON, but it lacks the required goal of being able to recover the values back.

Sure, I'm just recommending a default that rejects them or does what JavaScript does.

Hi @robermorales,

Thanks for creating this issue and the fork!

I had the same problem - I'm serializing a complex nested data structure with possible nan/infs, and it's difficult to replace all nan/infs manually before serializing. I was able to get away with simplejson's ignore_nan=True (so nan/infs get serialized as null), but I'm keeping an eye on your fork as well in case if consumers will have to distinguish between -infs/infs/nan.