[Python-Dev] A replacement for asyncore / asynchat

Panu A Kalliokoski atehwa@iki.fi
Tue, 17 Jul 2001 20:02:21 +0300 (EET DST)


On Tue, 17 Jul 2001, M.-A. Lemburg wrote:

| > For these reasons, I think that the asyncore package in the Python main
| > distribution should be replaced with Selecting or at least Selecting
| > should be put in the main distribution.
|
| Is your package backwards compatible to asyncore ? If not, then
| it might be a better idea, to place it on the web (e.g. on SourceForge)
| and  register the URLs with Parnassus so that Python users can
| easily find it.

I've registered the module in Parnassus. My point is mostly that because
Selecting really is (at least in my opinion) much easier to work with
than asyncore, it should be placed where people will look for standard
solutions, and that is the standard library.

Selecting is not backwards compatible with asyncore. It is not
impossible to write such glue code that one could use Selecting directly
in projects that have been written for asyncore, but I doubt whether it
is worth it. Selecting does not offer great advantages in performance
(at least not currently, but this might change), but in customisability
and clean API. asyncore does its work well in projects that use it, and
Selecting is mostly better because it is easier to make a new project
that uses it.

The sensible solution, as I see it, would be to deprecate
asyncore/asynchat but leave them there for supporting old projects, and
add Selecting as the primary way of abstracting over select() (and
poll(), kqueue and rtsig, which I plan to transparently add to
Selecting).

Panu