On Tue, May 5, 2015 at 2:40 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 5 May 2015 at 22:25, Guido van Rossum <guido@python.org> wrote:
[Paul:]
>> I'd be interested in writing, for instructional purposes, a toy but
>> complete event loop. But I'm *not* really interested in trying to
>> reverse engineer the required interface.
>
> This is a great idea. What kind of application do you have in mind?

At this point, *all* I'm thinking of is a toy. So, an implementation
somewhat parallel to asyncio, but where the event loop just passes
control to the next task - so no IO multiplexing. Essentially Greg
Ewing's example up to, but not including, "Waiting for External
Events". And ideally I'd like to think that "Waiting for Resources"
can be omitted in favour of reusing
https://docs.python.org/3/library/asyncio-sync.html and
https://docs.python.org/3/library/asyncio-queue.html. My fear is,
however, that those parts of asyncio aren't reusable for other event
loops, and every event loop implementation has to reinvent those
wheels.

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.
 
When I say "the required interface" I'm thinking in terms of "what's
needed to allow reuse of the generic parts of asyncio". If nothing of
asyncio is generic in those terms, then the exercise will be futile
(except in the negative sense of confirming that there are no reusable
async components in the stdlib).

Paul

What do you hope to learn or teach by creating this toy example? And how do you define "a complete event loop"?

--
--Guido van Rossum (python.org/~guido)