[Python-ideas] How the heck does async/await work in Python 3.5

[Guido van Rossum]

On Wed, Feb 24, 2016 at 10:49 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> My memory is that any replacement event loop is expected to be a full
> implmentation of the network io loop, so one cannot just make a gui loop
> that works with coroutines.

That's not correct. If an I/O loop does not implement the network I/O
APIs it just cannot be used for network I/O, but it can still
implement all the other functionality (like call_later). There are
other loops that don't implement everything (e.g. the subprocess and
datagram APIs are not supported by Proactor, and signal support is
spotty, too). If you find some implementation barrier that prevents
that from working it should be fixed.

[...]
> At this point, I am wondering whether it would be easier to forget the
> asynio network io loop and write from scratch a tkinter-based loop class
> that has the minimum needed to work with async and await code.  But what is
> that minimum?  PEP 492 "assumes that the asynchronous tasks are scheduled
> and coordinated by an Event Loop similar to that of stdlib module
> asyncio.events.AbstractEventLoop."  However, AsstractEventLoop is not that,
> but an abstract network/socket io event loop and a majority of the methods
> cannot be needed for non-network, non-socket code.
>
> Let me try again.  What is the actual minimal event loop api required by
> await?

The await expression (or yield from) does not require an event loop.
Heck, it doesn't require futures. It uses coroutines and it is totally
up to the manager of those how they are scheduled (read Greg Ewing's
very early explanations of yield from -- some have no I/O at all).

But there's something else that you might be after. The APIs related
to scheduling callbacks (timed or not) are the most fundamental. I
find run_until_complete() also fundamental, and requires a Future
class. So you need that (but you could have your own Future
implementation if you start from scratch or from AbstractEventLoop,
leaving the network I/O methods unimplemented. (After all they don't
use @abstractmethod so as long as you don't call them you should be
okay leaving them unimplemented.)

You really should be able to pick and choose, and the comments with
section names in AbstractEventLoop are meant to provide you with
guidance as to what to implement and what to leave out.

When you're implementing this API on top of tkinter, you'll probably
find that you'll have to use tkinter's way of sleeping anyways, so the
implementation of waiting in BaseEventLoop using a selector is not
useful for this scenario.

There are probably some possible refactorings in the asyncio package
to help you reuse a little more code, but all in all I still think it
would be very useful to have an asyncio loop integrated with Tkinter.
(Of course Tkinter does support network I/O, so it would be possible
to integrate with that, too. Or some hybrid where you somehow figure
out how to wait using a Selector *or* tkinter events in the same
loop.)

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