[Python-Dev] PEP 550 v4: coroutine policy

[Yury Selivanov]

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 = new_context_var()
>>    var = new_context_var()
>>
>>    async def bar():
>>        # EC = [current_thread_LC_copy, Task_foo_LC_copy, Task_wait_for_LC]
>
> 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 "wait_for()".

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
> Task_wait_for_LC, it may unwillingly affect wait_for() (assuming the
> wait_for() 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 wait_for() 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