<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 5, 2015 at 2:40 PM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 May 2015 at 22:25, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></span></blockquote><div>[Paul:] <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> I'd be interested in writing, for instructional purposes, a toy but<br>
>> complete event loop. But I'm *not* really interested in trying to<br>
>> reverse engineer the required interface.<br>
><br>
> This is a great idea. What kind of application do you have in mind?<br>
<br>
</span>At this point, *all* I'm thinking of is a toy. So, an implementation<br>
somewhat parallel to asyncio, but where the event loop just passes<br>
control to the next task - so no IO multiplexing. Essentially Greg<br>
Ewing's example up to, but not including, "Waiting for External<br>
Events". And ideally I'd like to think that "Waiting for Resources"<br>
can be omitted in favour of reusing<br>
<a href="https://docs.python.org/3/library/asyncio-sync.html" target="_blank">https://docs.python.org/3/library/asyncio-sync.html</a> and<br>
<a href="https://docs.python.org/3/library/asyncio-queue.html" target="_blank">https://docs.python.org/3/library/asyncio-queue.html</a>. My fear is,<br>
however, that those parts of asyncio aren't reusable for other event<br>
loops, and every event loop implementation has to reinvent those<br>
wheels.<br></blockquote><div><br></div><div>It was never a goal of asyncio to have parts that were directly reusable by other event loops without pulling in (almost) all of asyncio. The interoperability offered by asyncio allows other event loops to implement the same low-level interface as asyncio, or to build on top of asyncio. (This is why the event loop uses callbacks and isn't coroutines/generators all the way down.) Note that asyncio.get_event_loop() may return a loop implemented by some other framework, and the rest of asyncio will then use that event loop. This is enabled by the EventLoopPolicy interface.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I say "the required interface" I'm thinking in terms of "what's<br>
needed to allow reuse of the generic parts of asyncio". If nothing of<br>
asyncio is generic in those terms, then the exercise will be futile<br>
(except in the negative sense of confirming that there are no reusable<br>
async components in the stdlib).<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">What do you hope to learn or teach by creating this toy example? And how do you define "a complete event loop"?<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>