[Python-ideas] PEP 3156/Tulip: Extensible EventLoop interface

[Guido van Rossum]

On Tue, Feb 5, 2013 at 12:32 PM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 5 February 2013 04:50, Ben Darnell <ben at bendarnell.com> wrote:
>>> Still, it's a pretty weak argument IMO -- I don't expect there to be a
>>> significant cottage industry cranking out 3rd party protocol
>>> implementations, assuming we add UDP to PEP 3156, which is my plan.
>>
>> Yeah, as long as we get TCP, UDP, SSL, and pipes (at least for
>> subprocesses), I'm hard pressed to imagine anything else that would be in so
>> much demand it would need to be supported by all event loops.
>
> There are two thing that come to *my* mind whenever this sort of
> debate comes up. I'll freely admit that they are 100% theoretical in
> terms of my actual requirements, but neither is particular
> implausible.
>
> - Synchronisation primitlives like Windows event objects - wanting to
> integrate code to be run when an event is set into an event loop seems
> relatively reasonable.

Since this is about interacting with the threading world, you can
always wrap that in a concurrent.futures.Future, and then wrap that in
eventloop.wrap_future().

> - GUI input events - I don't know about Unix, but Windows GUI events
> are a separate notification stream from network or pipe data, and it's
> very plausible that someone would want to integrate GUI events into an
> async app. Twisted, for instance, has GUI event loop integration
> facilities, I believe.

That's way too large a topic to try to anticipate without thorough
research. And it's not very likely that you can do this in a portable
way either -- the best you can probably hope for is have a PEP
3156-compliant event loop that lets you use portable async networking
APIs (transports and protocols) while also letting you write
platform-*specific* GUI code. The best route here will probably be the
PEP 3156 bridge that Twisted is going to develop once the PEP and
Twisted's Python 3 port stabilize. (Unfortunately, wxPython is not
ported to Python 3.)

> (I know that "write your own event loop" is always a solution. But I'm
> not sure that doesn't set the bar a bit too high - it depends on how
> easy it is to reuse and extend the implementation of the standard
> event loops, which is something I'm not really clear on yet).

Check the most recent changes that landed in Tulip. The EventLoop
class has been refactored to bits and pieces, with exactly that
purpose in mind. (The PEP is a bit behind ATM, and I just broke the
ProactorEventLoop's ability to act as a server, but I'm on that.)

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