Home Original page

[Python-ideas] PEP draft: context variables

Guido van Rossum guido at python.org
Thu Oct 12 20:56:24 EDT 2017 
I'm out of energy to debate every point (Steve said it well -- that
decimal/generator example is too contrived), but I found one nit in Nick's
email that I wish to correct.

On Wed, Oct 11, 2017 at 1:28 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> As a less-contrived example, consider context managers implemented as
> generators.
>
> We want those to run with the execution context that's active when they're
> used in a with statement, not the one that's active when they're created
> (the fact that generator-based context managers can only be used once
> mitigates the risk of creation time context capture causing problems, but
> the implications would still be weird enough to be worth avoiding).
>

Here I think we're in agreement about the desired semantics, but IMO all
this requires is some special casing for @contextlib.contextmanager. To me
this is the exception, not the rule -- in most *other* places I would want
the yield to switch away from the caller's context.


> For native coroutines, we want them to run with the execution context
> that's active when they're awaited or when they're prepared for submission
> to an event loop, not the one that's active when they're created.
>

This caught my eye as wrong. Considering that asyncio's tasks (as well as
curio's and trio's) *are* native coroutines, we want complete isolation
between the context active when `await` is called and the context active
inside the `async def` function.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171012/03c14116/attachment-0001.html>
More information about the Python-ideas mailing list