> That's one of the reasons that a simple solution of "make JSONEncoder
> respect decimal.Decimal" was rejected -
I know concerns were raised, was it actually “rejected”? By whom, when?
it would require that the json
> module import decimal, which is extremely costly.
Is it though? I mean, relative to the whole process of encoding/decoding JSON — which is not exactly a high performance operation in any case.
The case has been made that JSON is used with large data sets, and this performance matters, but with a large JSON blob, import cost would not be the issue.
Which leaves things like small scripts that use JSON for configuration — I.e. short running processes that need to read/write JSON.
Finally: if JSON performance is important, than the built in lib may not be your best option anyway.
But anyway, for backwards compatibility, we probably wouldn’t want to change the default float-based JSON number encoding/decoding anyway, so there’s got to be a way to make the Decimal import optional.
Also, there are a lot of issues with import speed of semi-standard modules that cause issues with quickie scripts. If cPython really wants to be better at that, other methods will need to be found.
-CHB