[Python-Dev] Timeout for PEP 550 (original) (raw)

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

Nick Coghlan ncoghlan at gmail.com
Mon Oct 16 07:44:18 EDT 2017

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:

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>

More information about the Python-Dev mailing list