On 30 April 2015 at 07:01, Yury Selivanov
I think that the right approach here would be to have a standard protocol; something similar to how we defined WSGI -- it doesn't require any changes in the interpreter, it is a protocol.
+1 - I think we have reasonably good precedent for this in the form of atexit and there's also a proposal for an "atfork" manager: https://bugs.python.org/issue16500 Decimal contexts and (to a much lesser degree) fpectl are also interesting use cases, as is the event loop policy management in asyncio. One of the more interesting aspects of a context is its scope: * Can the same context be safely accessed from multiple threads concurrently? At different points in time? * Is there a "default context" which applies if no other context has been explicitly activated? By defining a global metacontext, it becomes feasible to sensibly manage things like the active asyncio event loop policy, the decimal context, etc, in ways that multiple frameworks can interoperate with. It's also potentially something that the logging module, pdb, and other tools could integrate with, by being able to better report the active context when requested. https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack is also an interest data point, as I can easily envision a variant of that API model that remembers what contexts *were* on the stack (this becoming a "ContextStack", rather than an "ExitStack"), making it easier to switch *between* stacks, rather than throwing them away when you're done. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia