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

Yury Selivanov yselivanov.ml at gmail.com
Tue Aug 29 16:54:54 EDT 2017

On Tue, Aug 29, 2017 at 4:33 PM, Antoine Pitrou <antoine at python.org> wrote:

Le 29/08/2017 à 22:20, Yury Selivanov a écrit :

2) gvar = newcontextvar() var = newcontextvar() async def bar(): # EC = [currentthreadLCcopy, TaskfooLCcopy, TaskwaitforLC] Ah, thanks!... That explains things, though I don't expect most users to spontaneously infer this and its consequences from the fact that they used "waitfor()".

Yeah, we use "# EC=" comments in the PEP to explain how EC is implemented for generators (in the Detailed Specification section), and will now do the same for coroutines (in the next update).

This seems actually even more problematic, because if bar() can mutate TaskwaitforLC, it may unwillingly affect waitfor() (assuming the waitfor() implementation may some day use EC for whatever purpose, e.g. logging).

In general the patter is to wrap the passed coroutine into a Task and then attach some callbacks to it (or wrap the coroutine into another coroutine). So while I understand the concern, I can't immediately come up with a realistic example...

It seems framework code like waitfor() should have a way to override the default behaviour and remove their own LC's from "child" coroutines' lookup chaines. Perhaps the PEP already allows for his?

Yes, the PEP provides enough APIs to implement any semantics we want. We might want to add "execution_context" kwarg to "asyncio.create_task" to make this customization of EC easy for Tasks.

Yury

More information about the Python-Dev mailing list