On May 26, 2006, at 6:27 PM, Steve Holden wrote: > Greg Ewing wrote: >> Fredrik Lundh wrote: >> >> >>> roughly speaking, epoll is kqueue for linux. >> >> >> There are many different select-like things around now >> (select, poll, epoll, kqueue -- are there others?) and >> random combinations of them seem to be available on any >> given platform. This makes writing platform-independent >> code that needs select-like functionality very awkward. >> >> Rather than adding yet another platform-dependent module, >> I'd like to see a unified Python interface in the stdlib >> that uses whichever is the best one available. >> > Of course that would mean establishing which *was* the best available > which, as we've seen this week, may not be easy. I believe it's: kqueue on FreeBSD (for recent-enough versions thereof), otherwise epoll where available and nonbuggy, otherwise poll ditto, otherwise select -- that's roughly what Twisted uses for Reactor implementations, if memory serves me well. The platform- based heuristic should try to identify things this way but let the developer easily override if they know better. (One might add a Windows event loop as the best implementation available there -- Twisted does -- and GUI toolkit based event loops -- but in general that takes an abstraction level similar to Twisted's Reactor... maybe we should just repurpose that bit of Twisted?-) I don't think this is feasible for 2.5 (too late in the cycle to add major new stuff, IMHO), but it's well worth it for 2.6 (again IMHO). Alex
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