On Aug 23, 2019, at 00:33, Richard Musil email@example.com wrote:
Why simplejson remained separated from the main CPython is also a question (I guess there was/is a reason), because it seems like including the code completely and maintain it inside CPython could be better use of the resources.
The README explains that: “simplejson is the externally maintained development version of the json library included with Python 2.6 and Python 3.0”.
This has multiple advantages:
* It can evolve much more quickly than the 18-month stdlib cycle. Notice that it’s gone from 1.0 to 3.16.1 during the time Python has only had 5 releases.
* It can add features that aren’t appropriate for the stdlib.
* It can add features that might be appropriate for the stdlib or might not, to gain experience with real-world use before deciding.
* It works the same way on all of Python 2.5+ and 3.3+ (including PyPy, etc.), rather than new features only being available in the newest Python; if there were no simplejson there would be a backports.json or json35 or whatever module on PyPI instead.
Bob Ippolito has said in the past that simplejson has grown too many options, which can’t be removed for backward compatibility reasons, so it’s a good thing the stdlib doesn’t have all of them. The fact that the stdlib can add _one_ of them, after years of use in the wild, while ignoring all of the others, is exactly why it’s a good thing simplejson exists as a separate project.
But you can’t just port the feature as-is, because I’m pretty sure unconditionally importing decimal is the main reason simplejson is slower to import than json. You will need to add some way around that (whether a simple lazy import on first use, or one of the more clever ideas people have brought up on this thread).
Also, IIRC, it doesn’t do any post-check; it assumes calling str on any Decimal value (after an isfinite check if not allow_nan) produces valid JSON. I think there are unit tests meant to establish that fact, but you’d need to copy those into the stdlib test suite and make the case that their coverage is sufficient, or make some other argument that it’s guaranteed to be safe, or ignore str and write a _decimal_str similar to the existing _float_str, or find a way to validate it that isn’t too slow.