[Python-ideas] Add a generic async IO poller/reactor to select module

[Nick Coghlan]

On May 25, 2012 7:33 PM, "Calvin Spealman" <ironfroggy at gmail.com> wrote:

> On Wed, May 23, 2012 at 9:32 PM, Giampaolo Rodolà <g.rodola at gmail.com>
> wrote:
> > Users willing to support multiple event loops such as wx, gtk etc can do:
> >
> >>>> while 1:
> > ...       poller.poll(timeout=0.1, blocking=False)
> > ...       otherpoller.poll()
> >
> >
> > Basically, this would be the whole API.
> >
> > Thoughts?
> >
>
> Frankly, I don't think this deserves a PEP at all, or even to consider
> one *yet*.
>
> Building a new API and a new library from scratch seems a frail
> comparison to testing
> a library in the real world, it having real uses, and then being
> incorporated into the
> stdlib. The problem here, of course, is that all the real-world
> solutions (ie, Twisted)
> include far more than the reactor.
>

No, the specific call at the PyCon US 2011 language summit was for a PEP
that proposed a *new* event loop for the standard library that:
1. Provides simple event loop functionality in the standard library, as an
improved alternative to asyncore for small apps that don't require the full
power of a framework like Twisted (think things like little IRC bots, TCP
echo servers, or testing of async components)
2. Provides a clean migration path to a production grade reactor like
Twisted's
3. Makes it easier for multiple event loop based frameworks (e.g. tkinter,
wxPython, PySide, Twisted) to all cooperate within the same process

What we're after is something for the stdlib that is to event
loops/reactors as wsgiref is to production grade WSGI servers like mod_wsgi
and nginx. asyncore isn't it, because the migration path isn't clean.

PEP 3153 currently spends a lot of time talking about transports and
protocols, but doesn't answer those 3 core questions:

1. How do I write a simple IRC bot or TCP echo server?
2. How do I migrate my simple app to a production grade reactor like
Twisted's?
3. How do I run two different concurrent.eventloop compatible reactors in
the same process?

As far as I can tell, PEP 3153 wants to handle all that by merging the I/O
stacks of all the frameworks first, which strikes me as being *way* too
ambitious for a first step. If we can't even figure out a common
abstraction for the reactor level (ala WSGI), how are we ever going to
agree on a standard async I/O abstraction?

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120525/0cbff963/attachment.html>