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

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).

the socketserver even documents that it would like to have such a framework ("Future work: [...] Standard framework for select-based multiplexing"). it would be rather difficult to port in the generic case (as socketserver based code in general relies on blocking `read`s or `readline`s), but can be done in particular cases (i've ported SimpleHTTPServer, but it's a mess of monkey-patching). for subprocess, there's a bunch of recipies at [1]; pyserial (not standard library, but might as well become) can be ported quite easily [2].

[1] http://code.activestate.com/recipes/576957-asynchronous-subprocess-using-asyncore/
[2] http://sourceforge.net/tracker/?func=detail&aid=3559321&group_id=46487&atid=446305


this issue touches several modules, so for practical implementation, it might be split up for the different individual fixes to come and track them. some of them will bring incompatible changes -- it's easy to get SimpleHTTPServer to a state where it can run unmodified inside asyncore, and emulate its external interfaces (serve_forever just being a wrapper to asyncore.loop), but hard to say if it will work with what people built atop of it. how can we find a roadmap for that?

python already has batteries for nonblocking operation included -- let's just make sure they fit in the other gadgets!