[Python-Dev] PEP 492 quibble and request
Steve.Dower at microsoft.com
Fri May 1 17:25:18 CEST 2015
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 Moore<mailto:p.f.moore at gmail.com>
Sent: 4/30/2015 2:07
To: Greg Ewing<mailto:greg.ewing at canterbury.ac.nz>
Cc: Python Dev<mailto:python-dev at python.org>
Subject: Re: [Python-Dev] PEP 492 quibble and request
On 30 April 2015 at 09:58, Greg Ewing <greg.ewing at 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.
Python-Dev mailing list
Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev