(original) (raw)
On Sun, Oct 15, 2017 at 8:17 PM, Nathaniel Smith <njs@pobox.com> wrote:
If you want to ignore generators/async generators, then I think youOn Sun, Oct 15, 2017 at 6:33 PM, Yury Selivanov <yselivanov.ml@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.
don't even want PEP 550 v1, you just want something like a
{set,get}\_context\_state API that lets you access the ThreadState's
context dict (or rather, an opaque ContextState object that holds the
context dict), and then task schedulers can call them at appropriate
moments.
Yes, that's what I meant by "ignoring generators". And I'd like there to be a "current context" that's a per-thread MutableMapping with ContextVar keys. Maybe there's not much more to it apart from naming the APIs for getting and setting it? To be clear, I am fine with this being a specific subtype of MutableMapping. But I don't see much benefit in making it more abstract than that.