"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4