[Python-Dev] PEP 550 v4 (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Tue Aug 29 19:34:27 EDT 2017

On Tue, Aug 29, 2017 at 7:06 PM, Stefan Krah <stefan at bytereef.org> wrote:

On Tue, Aug 29, 2017 at 06:01:40PM -0400, Yury Selivanov wrote:

PEP 550 positions itself as a replacement for TLS, and clearly defines its semantics for regular functions in a single thread, regular functions in multithreaded code, generators, and asynchronous code (async/await). Everything is specified in the High-level Specification section. I wouldn't call slightly differently defined semantics for generators/coroutines/functions an "inconsistency" -- they just have a different EC semantics given how different they are from each other. What I don't find so consistent is that the async universe is guarded with async {def, for, with, ...}, but in this proposal regular context managers and context setters implicitly adapt their behavior. So, pedantically, having a language extension like async set(var, value) x = async get(var) and making async-safe context managers explicit async with decimal.localcontext(): ...

would feel more consistent. I know generators are a problem, but even allowing something like "async set" in generators would be a step up.

But regular context managers work just fine with asynchronous code. Not all of them have some local state. For example, you could have a context manager to time how long the code wrapped into it executes:

  async def foo():
        with timing():
              await ...

We use asynchronous context managers only when they need to do asynchronous operations in their aenter and aexit (like DB transaction begin/rollback/commit).

Requiring "await" to set a value for context variable would force us to write specialized async CMs for cases where a sync CM would do just fine. This in turn, would make it impossible to use some sync libraries in async code. But there's nothing wrong in using numpy/numpy.errstate in a coroutine. I want to be able to copy/paste their examples into my async code and I'd expect it to just work -- that's the point of the PEP.

async/await already requires to have separate APIs in libraries that involve IO. Let's not make the situation worse by asking people to use asynchronous version of PEP 550 even though it's not really needed.

Yury

More information about the Python-Dev mailing list