Guido van Rossum added the comment: On Sat, Aug 24, 2013 at 5:04 AM, Charles-François Natali <rep...@bugs.python.org> wrote: > Before I post it for final review, I have three more questions: > 1) In the documentation, I don't know how to best refer to files > object registered: is "file descriptor" OK, or is it too low-level? > Otherwise I'd be tempted to use just "file", but then this doesn't > include sockets, pipes, etc. Or maybe "file object"/"file-like > object"?
What Antoine said. And, moreover, it should be mentioned that on Windows it only accepts socket FDs; and on UNIX it should probably qualify this in some way to exclude disk FDs (which are always considered ready by select and friends). I don't really know what the correct UNIX-flavor-neutral terminology is for this case -- perhaps we have to enumerate the possibilities? (I know of FIFOs, character special devices, and sockets.) > 2) currently, the select() method returns a list of > (<file>, <event>, <data>) > > But the opaque "data" object is optional, which means that many user > might end up doing: > > for file, event, data in selector.select(): > if event & READ_EVENT: > file.recv(1024) > # don't use data > > i.e. have to unpack it for no reason. > > Would it make sense to return (<key>, <event>) instead? > This way the user has all the interesting information, and can do: > > for key, event in selector.select(): > if event & READ_EVENT: > key.file.recv(1024) > or > os.read(key.fd, 1024) I like this -- return the key plus the specific event. You must document SelectorKey, but that seems fine. (Looks like Antoine read too fast and didn't realize you proposed to return the key instead of the file and the data.) > 3) Concerning get_info(): right now the signature is: > get_info(): fileobj -> (events, data) > > Wouldn't it be better to just return the whole key instead, which > contains all the relevant information (events, data, fd and fileobj). > Then we should probably also rename the method to get_key()? Yes, and yes. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
