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.