On Tue, Feb 5, 2013 at 12:32 PM, Paul Moore
On 5 February 2013 04:50, Ben Darnell
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)