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.
Top-posted from my Windows Phone ________________________________ From: Paul Mooremailto:firstname.lastname@example.org Sent: 4/30/2015 2:07 To: Greg Ewingmailto:email@example.com Cc: Python Devmailto:firstname.lastname@example.org Subject: Re: [Python-Dev] PEP 492 quibble and request
On 30 April 2015 at 09:58, Greg Ewing email@example.com 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.c...