[Python-Dev] PEP 492: async/await in Python; version 5

[Guido van Rossum]

I wonder if you could look at Tkinter for a very different view of the
world. While there are ways to integrate socket I/O with the Tcl/Tk event
loop, the typical Python app using Tkinter probably moves network I/O (if
it has any) to a separate thread, and ignores the delays of disk-based I/O
(because modern disk I/O is usually faster than the minimal event response
time -- assuming you don't have floppy disks :-).

I'm not entirely sure how you would use coroutines with Tkinter, but I
could imagine that e.g. mouse tracking code such as found in drawing apps
might be written more easily using a loop that uses await (or yield [from])
to get another event rather than as a callback function for the "mouse
move" event.

The mechanics of writing a multiplexer that receives Tkinter events and
uses them to decide which generator/coroutine to wake up might be too much
for your purpose, but it would provide a real-life example of an event loop
that's not built for network I/O.

On Tue, May 5, 2015 at 3:52 PM, Paul Moore <p.f.moore at gmail.com> wrote:

> On 5 May 2015 at 23:28, Guido van Rossum <guido at python.org> wrote:
> >> 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.
>
> OK, that's an entirely fair comment. It's difficult to tell from the
> docs - there's nothing obviously io-related about the task
> abstraction, or the synchronisation or queue primitives. But there's
> equally no reason to assume that they would work with another
> implementation. As I mentioned somewhere else, maybe refactoring the
> bits of asyncio that can be reused into an asynclib module would be
> useful. But based on what you said, there's no reason to assume that
> would be an easy job. And without another event loop implementation,
> it's not obvious that there's a justification for doing so.
>
> > What do you hope to learn or teach by creating this toy example? And how
> do
> > you define "a complete event loop"?
>
> Well, one thing I hope to learn, I guess, is what "a complete event
> loop" consists of :-)
>
> More broadly, I'd like to get a better feel for what methods are
> fundamental to an event loop. IIRC, we had this discussion way back at
> the beginning of the asyncio development when I was unclear about why
> create_connection had to be an event loop method. In the asyncio
> context, it has to be because the event loop needs to know when
> connections get created (excuse me probably misremembering the exact
> reason from back then). But conversely, it's easy to imagine an event
> loop unrelated to socket IO that doesn't have a create_connection
> method. On the other hand, an event loop with no call_soon method
> seems unlikely. So in essence I'm thinking about what a "sensible
> minimum" event loop might be. An event loop ABC, if you like.
>
> And following on from there, what useful abstractions (tasks,
> synchronisation and queue primitives) can be built on top of such a
> minimal interface. Basically, that's what I'm hoping to learn - what
> is fundamental (or at least generally applicable) and what is related
> to the purpose of a given implementation.
>
> I've probably got enough from this discussion to try writing up some
> code and see where it leads me.
>
> Paul
>
> PS You mentioned that a the callback-based nature of the asyncio event
> loop is to simplify interoperability with callback-based frameworks
> like Twisted. I guess the above ignores the possibility of event loops
> that *aren't* callback-based. Or maybe it doesn't - that's possibly
> another class of methods (callback-focused ones) that maybe can be
> separated into their own ABC.
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150505/23bcf81d/attachment.html>