> How about "not *only* as a separate set of calls"? If poll(2) and > epoll(4) are both available on the underlying platform, then they > should both be exposed to Python as separate APIs. Then, on top of > that, a relatively simple layer which selects the most efficient > mechanism can be exposed, and developers can be encouraged to use > that instead. Why does it have to be a separate API? Isn't the edge-triggered mode just a matter of passing EPOLLET into register? If so, I would advise against having two sets of functions, although having two sets of constants is propably fine. I would just provide a second constructor, select.epoll(), which guarantees that epoll is used as the implementation strategy (i.e. it would raise OSError if the kernel doesn't support epoll_create). Regards, Martin
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