[Python-ideas] asyncore: included batteries don't fit

Giampaolo Rodolà g.rodola at gmail.com
Tue Sep 25 00:31:37 CEST 2012


I still think this proposal is too vaguely defined and any effort towards
adding async IO support to existing batteries is premature for different
reasons, first of which the inadequacy of asyncore as the base async
framework to fulfill the task you're proposing.

asyncore is so old and difficult to fix/enhance without breaking backward
compatibility (see for example http://bugs.python.org/issue11273#msg156439)
that relying on it for any modern work is inevitably a bad idea.

>From a chronological standpoint I still think the best thing to do in order
to fix the "python async problem" once and for all is to first define and
possibly implement an "async WSGI interface" describing what a standard
async IO loop/reactor should look like (in terms of API) and how to
integrate with it, see:
http://mail.python.org/pipermail/python-ideas/2012-May/015223.html
http://mail.python.org/pipermail/python-ideas/2012-May/015235.html

>From there the python stdlib *might* grow a new module implementing the
"async WSGI interface" (let's call it asyncore2) and some of the stdlib
batteries such as socketserver can possibly use it.

In my mind this is the ideal long-term scenario but even managing to define
an "async WSGI interface" alone would be a big step forward.

Again, at this point in time what you're proposing looks too vague,
ambitious and premature to me.


--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/



2012/9/22 chrysn <chrysn at fsfe.org>

> hello python-ideas,
>
> i'd like to start discussion about the state of asyncore/asynchat's
> adaption in the python standard library, with the intention of finding a
> roadmap for how to improve things, and of kicking off and coordinating
> implementations.
>
> here's the problem (as previously described in [issue15978] and
> redirected here, with some additions):
>
> the asyncore module would be much more useful if it were well integrated
> in the standard library. in particular, it should be supported by:
>
> * subprocess
>
> * BaseHTTPServer / http.server (and thus, socketserver)
>
> * urllib2 / urllib, http.client
>
> * probably many other network libraries except smtpd, which already uses
>   asyncore
>
> * third party libraries (if stdlib leads the way, the ecosystem will
>   follow; eg pyserial)
>
> without widespread asyncore support, it is not possible to easily
> integrate different servers and services with each other; with asyncore
> support, it's just a matter of creating the objects and entering the
> main loop. (eg, a http server for controlling a serial device, with a
> telnet-like debugging interface).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120924/2991ca3b/attachment.html>


More information about the Python-ideas mailing list