<br><br><div><span class="gmail_quote">On 12/20/07, <b class="gmail_sendername">Ross Cohen</b> <<a href="mailto:rcohen@snurgle.org">rcohen@snurgle.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, Dec 20, 2007 at 06:08:47PM +0100, Christian Heimes wrote:<br><br>> I've written wrappers for both mechanisms. Both wrappers are inspired<br>> from Twisted and select.poll()'s API. The interface is more Pythonic
<br>> than the available wrappers and it reduced the burden on the user. The<br>> users don't have to deal with low level control file descriptors and the<br>> fd is closed automatically when the object is collected.
<br><br>Did you look at the python-epoll module which has been in the Cheese<br>Shop for quite some time? There is no messing with a low level control<br>file descriptor and it presents an identical interface to select.poll
().<br><br>I would claim this whole new interface:<br><br>> epoll interface<br>><br>> >>> ep = select.epoll(1)<br>> >>> ep.register(fd, select.EPOLL_IN | select.EPOLL_OUT)<br>> >>>
ep.modify(fd, select.EPOLL_OUT)<br>> >>> events = ep.wait(1, 1000)<br>> >>> ep.unregister(fd)<br><br>Is a greater burden on the user than:<br><br>>>> import epoll as select<br><br>I would also claim that adding a new interface to accomplish the same
<br>task is not more pythonic. But I did write the python-epoll module in<br>question, so I may be a bit biased.<br><br>Ross</blockquote><div><br>Providing a compatibility layer that mirrors the select.select or select.poll
interface using the best underlying syscall may be nice but... In order to gain the most benefit from any of these system calls they should be exposed directly. Do the compatibility wrapping in python but leave the low level calls exposed for those that want them, they make a big difference to what an application can do. (i believe kqueue/kevent can handle signals, etc)
<br> <br>I like this patch.<br></div></div>