Using asyncio in event-driven network library

[Terry Reedy]

On 12/23/2013 11:47 AM, Chris Angelico wrote:
> On Mon, Dec 23, 2013 at 10:50 PM, Tobias M. <tm at tobix.eu> wrote:
>> I am currently writing an event-driven client library for a network protocol
>> [1] and chose to use the new asyncio module. I have no experience with
>> asynchronous IO and don't understand all the concepts in asyncio yet. So I'm
>> not sure if asyncio is actually the right choice .
>
> As was acknowledged on -tutor, asyncio is extremely new. I don't know
> if anyone's yet used it for GUI handling, or even if the module was
> intended for that.

Asyncio is aimed, as the name says, at non-blocking io, but allows 
non-blocking on other tasks. It replaces asyncore, now deprecated (but 
not removed). Developers of Twisted, Tornado, and other async frameworks 
had input. It was partly inspired, I think, by C#'s await, which allows 
async code to look much like normal blocking code (Guido does not like 
writing callbacks ;-). The default event loop is intended to be 
replaceable by other event loops that expose the same interface.

I know that Twisted can work with GUI loops but I do not know the 
details.  I suspect that the same methods can and will be make to work 
with the asyncio loop, or that the Twisted loop will get an adaptor so 
it can replace the asyncio default loop.

What would be easiest for user-developers would be if someone were able 
to wrap a gui loop in a way to give it the needed interface, so the gui 
loop itself replaced and became the asyncio loop.

> You may be able to wrap your GUI code up so it fits inside asyncio.
> Rather than run a simple event loop, you could have your own loop that
> does some kind of checking: PyGTK has functions for peeking at events
> and doing just one iteration of the main loop, so you could pump all
> events with something like this:
>
> while gtk.events_pending(): gtk.main_iteration()
>
> No doubt other toolkits have something similar.

I think tk(inter) has 'run pending events' or something.

> Alternatively, you could run two threads: one for your GUI, and
> another one for your asyncio. How easy and clean that would be is hard
> to say without trying it; it could work out beautifully for your code,
> or it could be horribly clunky.
>
> This might be your big contribution to Python for the year: a nice,
> easy, working example of using asyncio with a GUI toolkit!

Such would definitely be welcome.

-- 
Terry Jan Reedy