On Wed, Apr 29, 2015 at 6:53 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
+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?
I've thought about these and other issues for quite some time. :) I have an old implementation of a generic context type kicking around that came out of my initial work on the "Import Engine" PEP. At the time it seemed genuinely useful and would have been used in decimal and maybe for email policies (in addition to import system contexts). I'm spinning back up on the successor to that PEP, which is part of why I brought "async-local" contexts the other day.
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.
+1
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.
interesting. -eric