> > 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. (https://pythonspeed.com/articles/faster-json-library/) 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 -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FU7FHMT72YYST3NMZZFEFNYNFMQTMLED/ Code of Conduct: http://python.org/psf/codeofconduct/
