[Python-Dev] PEP 550 v4

[Yury Selivanov]

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