The high-level answer to this is, like yield, the function temporarily returns all the way up the stack to the caller who intends to advance the iterator/async function. This is typically the event loop, and the main confusion here comes when the loop is implicit.

If you explicitly define an event loop it's roughly equivalent to the for loop that is calling next on a generator. For pip, I expect that's what you'd have - a blocking function ("do_work()"?, "execute_plan()"?) that creates a loop and starts it's tasks running within it. Each task inside that call with be asynchronous with respect to each other (think about passing generators to zip() ) but the loop will block the rest of your code until they're all finished.

Cheers,
Steve

Top-posted from my Windows Phone

From: Paul Moore
Sent: 4/30/2015 2:07
To: Greg Ewing
Cc: Python Dev
Subject: Re: [Python-Dev] PEP 492 quibble and request

On 30 April 2015 at 09:58, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> Ethan Furman wrote:
>>
>> Having gone through the PEP again, I am still no closer to understanding
>> what happens here:
>>
>>   data = await reader.read(8192)
>>
>> What does the flow of control look like at the interpreter level?
>
>
> Are you sure you *really* want to know? For the sake
> of sanity, I recommend ignoring the actual control
> flow and pretending that it's just like
>
>    data = reader.read(8192)
>
> with the reader.read() method somehow able to be
> magically suspended.

Well, if I don't know, I get confused as to where I invoke the event
loop, how my non-async code runs alongside this etc.
Paul
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com