> >> I'd suggest adding poll() to 2.0, and will submit a patch if given the > >> go-ahead. But where should it go? A whole module for it seems > >> excessive; should it go in posixmodule, or maybe select? > > I've completed a patch, SF#100852, to add os.poll() based on Sam > Rushing's code with various modifications; I'd like a reviewer to look > it over, after which I'll check it in. > > http://sourceforge.net/patch/?func=detailpatch&patch_id=100852&group_id=5470 > > I'm not happy with the interface -- you pass in a list of (file > descriptor, event mask) 2-tuples -- but it seems the only way to > expose all of poll()'s functionality. I thought about allowing a lone > file descriptor as well as a tuple, in which you'd assume an event > mask of POLLIN | POLLPRI | POLLOUT (all the common events), but it > seemed like too much magic. I haven't read the patch in detail, but this approach seems reasonable. Somehow I don't understand why we need poll() when we have select(), however. Select() is portable, poll() is Unix specific, but it seems to provide the same functionality. What am I missing? > Also, is there a C utility function to handle the "pass an integer or > an object with a fileno() method" protocol for me? Should there be > one? This is a nice refactoring opportunity. The code probably exists in many places, e.g. selectmodule.c. It should be a function in fileobject.c, I suppose. --Guido van Rossum (home page: http://dinsdale.python.org/~guido/)
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