[Python-Dev] Test cases for asynchat, asyncore?

[Sam Rushing]

"Barry A. Warsaw" wrote:

> Oh, one other thing.  Last time I traded email with Sam Rushing
> (almost a year ago, and I'm not even sure if he's on python-dev), he
> was moving toward a coroutine based Medusa and away from async* based.

One of the reasons I originally offered them into the distribution was
that those two modules were always distributed under a standard python
license, while the rest of medusa was still 'commercial'.  Since that's
no longer the case, there's less of a reason to have it in the standard
lib.  [But I think there are a lot of async* users out there...]

Coupla other points:

  1) there are folks (myself included) that would like to see a new
design for asyncore and asynchat, one that doesn't require the expensive
polling of objects and that can have lots of its underbelly parts
replaced with C when necessary.  A totally new 'official' facility that
was aware of and could take advantage of the features of /dev/poll,
kqueue, rtsig, etc.. would be way cool.  I don't think that backward
compatibility would be all that important, since most software uses
async* in a 'shallow' way rather than a 'deep' way - it's be easy to
recode to a newer more efficient API.

  2) it'll be a while before anything polished will be along to obsolete
async*/medusa.  I'm currently working with kqueue and stackless
coroutines but don't know when/if I might be able to release the code.
Such a beast will be radically different from medusa, and would certainly
have a new name...  it's almost more of a 'python-level user-threading
package' (like uthread) than a replacement for async*.

-Sam