<p dir="ltr">On May 5, 2015 12:40 PM, "Jim J. Jewett" <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492.<br>
><br>
> Where are the following over-simplifications wrong?<br>
><br>
[...snip...]<br>
><br>
> [Note that the actual PEP uses iteration over the results of a new<br>
> __await__ magic method, rather than .result on the object itself.<br>
> I couldn't tell whether this was for explicit marking, or just for<br>
> efficiency in avoiding future creation.]<br>
><br>
> (4)  "await EXPR" is just syntactic sugar for EXPR.result<br>
><br>
> except that, by being syntax, it better marks locations where<br>
> unrelated tasks might have a chance to change shared data.<br>
><br>
> [And that, as currently planned, the result of an await isn't<br>
> actually the result; it is an iterator of results.]</p>
<p dir="ltr">This is where you're missing a key idea. (And I agree that more high-level docs are very much needed!) Remember that this is just regular single threaded python code, so just writing EXPR.result cannot possibly cause the current task to pause and another one to start running, and then magically switch back somehow when the result does become available. Imagine trying to implement a .result attribute that does that -- it's impossible.</p>
<p dir="ltr">Writing 'x = await socket1.read(1)' is actually equivalent to writing a little loop like:</p>
<p dir="ltr">while True:<br>
    # figure out what we need to happen to make progress<br>
    needed = "data from socket 1"<br>
    # suspend this function,<br>
    # and send the main loop a message telling it what we need<br>
    reply = (yield needed)<br>
    # okay, the main loop woke us up again<br>
    # let's see if they've sent us back what we asked for<br>
    if reply.type == "data from socket 1":<br>
        # got it!<br>
        x = reply.payload<br>
        break<br>
    else:<br>
        # if at first you don't succeed...<br>
        continue</p>
<p dir="ltr">(Now stare at the formal definition of 'yield from' until you see how it maps onto the above... And if you're wondering why we need a loop, think about the case where instead of calling socket.read we're calling http.get or something that requires multiple steps to complete.)</p>
<p dir="ltr">So there actually is semantically no iterator here -- the thing that looks like an iterator is actually the chatter back and forth between the lower-level code and the main loop that is orchestrating everything. Then when that's done, it returns the single result.</p>
<p dir="ltr">-n</p>