I agree with Raymond. The "implicit context" pattern is really only desirable in a small subset of situations, and I don't think configuring JSON serialization is one of those. (it may even be an active nuisance, because some libraries may be using JSON as an implementation detail and a "JSON context" might break those libraries by changing important settings they rely on) Regards Antoine. On Thu, 06 Aug 2020 20:15:27 -0000 raymond.hettinger@gmail.com wrote:
Based on experience with the decimal module, I think this would open a can of worms. To match what decimal does, we would need a Context() object with methods for dump, dumps, load, loads. There would need to be a thread-local or contextvar instance accessed by getcontext and setcontext, and perhaps a decorator as well. We would need a few pre-made instances for common cases.
Also, the decimal module was context aware from the outset. For JSON, we have large body of pre-existing client code that was created and tested without the concept of a context. Should existing code use the new context and possibly break assumed invariants? If the existing code had explicit parameters (such as indent=4), would the context override the parameter, take a backseat to the parameter, or raise an exception? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/KAD3U5... Code of Conduct: http://python.org/psf/codeofconduct/