> 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.


Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython