[Python-ideas] Letting context managers react to yields inside their scope

[Eric Snow]

On Wed, Apr 29, 2015 at 6:53 PM, Nick Coghlan <ncoghlan at 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