[Python-Dev] Minimal async event loop and async utilities (Was: PEP 492: async/await in Python; version 4)

[Paul Moore]

On 6 May 2015 at 07:46, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Another problem with the "core" idea is that
> you can't start with an event loop that "just does
> scheduling" and then add on other features such
> as I/O *from the outside*. There has to be some
> point at which everything comes together, which
> means choosing something like select() or
> poll() or I/O completion queues, and build that
> into the heart of your event loop. At that point
> it's no longer something with a simple core.

Looking at asyncio.queues, the only features it needs are:

1. asyncio.events.get_event_loop()
2. asyncio.futures.Future - creating a standalone Future
3. asyncio.locks.Event
4. @coroutine

locks.Event in turn only needs the other 3 items. And you can ignore
get_event_loop() as it's only used to get the default loop, you can
pass in your own.

And asyncio.futures only uses get_event_loop (and _format_callback)
from asyncio.events.

Futures require the loop to support:
1. call_soon
2. call_exception_handler
3. get_debug

So, to some extent (how far is something I'd need to code up a loop to
confirm) you can build the Futures and synchronisation mechanisms with
an event loop that supports only this "minimal interface".

Essentially, that's my goal - to allow people who want to write (say)
a Windows GUI event loop, or a Windows event loop based of
WaitForXXXObject, or a Tkinter loop, or whatever, to *not* have to
write their own implementation of synchronisation or future objects.

That may mean lifting the asyncio code and putting it into a separate
library, to make the separation between "asyncio-dependent" and
"general async" clearer. Or if asyncio's provisional status doesn't
last long enough to do that, we may end up with an asyncio
implementation and a separate (possibly 3rd party) "general"
implementation.

Paul.