A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2017-August/149061.html below:

[Python-Dev] PEP 550 v4: coroutine policy

[Python-Dev] PEP 550 v4: coroutine policyAntoine Pitrou antoine at python.org
Tue Aug 29 16:10:01 EDT 2017
Le 29/08/2017 à 21:59, Yury Selivanov a écrit :
> 
> This absolutely needs to be fixed, and the only way (that I know) it
> can be fixed is to revert the "every coroutine has its own LC"
> statement (going back to the semantics coroutines had in PEP 550 v2
> and v3).

I completely agree with this.  What I don't understand is why example #2
can't work the same.

> "await bar()" and "await wait_for(bar())" are actually quite
> different.  Let me illustrate with an example:
> 
>     b1 = bar()
>     # bar() is not running yet
>     await b1
> 
>     b2 = wait_for(bar())
>     # bar() was wrapped into a Task and is being running right now
>     await b2
> 
> Usually this difference is subtle, but in asyncio it's perfectly fine
> to never await on b2, just let it run until it completes.  If you
> don't "await b1" -- b1 simply will never run.

Perhaps... But still, why doesn't bar() inherit the LC *at the point
where it was instantiated* (i.e. foo()'s LC in the examples)?  The fact
that it's *later* passed to wait_for() shouldn't matter, right?  Or
should it?

Regards

Antoine.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4