[Python-Dev] Timeout for PEP 550 / Execution Context discussion

[Nick Coghlan]

On 16 October 2017 at 18:26, Paul Moore <p.f.moore at gmail.com> wrote:

> On 16 October 2017 at 02:33, Yury Selivanov <yselivanov.ml at gmail.com>
> wrote:
> > Stage 1. A new execution context PEP to solve the problem *just for
> > async code*.  The PEP will target Python 3.7 and completely ignore
> > synchronous generators and asynchronous generators.  It will be based
> > on PEP 550 v1 (no chained lookups, immutable mapping or CoW as an
> > optimization) and borrow some good API decisions from PEP 550 v3+
> > (contextvars module, ContextVar class).  The API (and C-API) will be
> > designed to be future proof and ultimately allow transition to the
> > stage 2.
>
> So would decimal contexts stick to using threading.local? If so,
> presumably they'd still have problems with async. If not, won't you
> still be stuck with having to define the new semantics they have when
> used with generators? Or would it be out of scope for the PEP to take
> a position on what decimal does?
>

Decimal could (and should) still switch over in order to make itself more
coroutine-friendly, as in this version of the proposal, the key design
parameters would be:

- for synchronous code that never changes the execution context, context
variables and thread locals are essentially equivalent (since there will be
exactly one execution context per thread)
- for asynchronous code, each task managed by the event loop will get its
own execution context (each of which is distinct from the event loop's own
execution context)

So while I was initially disappointed by the suggestion, I'm coming around
to the perspective that it's probably a good pragmatic way to improve
context variable adoption rates, since it makes it straightforward for
folks to seamlessly switch between using context variables when they're
available, and falling back to thread local variables otherwise (and
perhaps restricting their coroutine support to Python versions that offer
context variables).

The downside is that you'll still need to explicitly revert the decimal
context before yielding from a generator if you didn't want the context
change to "leak", but that's not a new constraint - it's one that already
exists for the thread-local based decimal context API.

So going down this path would lock in the *default* semantics for the
interaction between context variables and generators as being the same as
the interaction between thread locals and generators, but would still leave
the door open to subsequently introducing an opt-in API like the
"contextvars.iter_in_context" idea for cases where folks decided they
wanted to do something different (like capturing the context at the point
where iterator was created and then temporarily switching back to that on
each iteration).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171016/2b5651e9/attachment.html>