Author neologix
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt, vstinner
Date 2013-08-24.12:04:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM3-7x_i3vJtF8ZNf5ia0hCBBUU6MCq4W9r2h1UH8n+KeA@mail.gmail.com>
In-reply-to <CAP7+vJKP=mkOhqS6VnbLf3bjRnM8RdAVYCbUDdkgKznM_rMyWQ@mail.gmail.com>
Content
Alright, I've updated the patch to have a distinct selectors module,
and with Guido's comments.

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"?

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)

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()?
History
Date User Action Args
2013-08-24 12:04:15neologixsetrecipients: + neologix, gvanrossum, pitrou, vstinner, giampaolo.rodola, christian.heimes, meador.inge, rosslagerwall, sbt, felipecruz
2013-08-24 12:04:15neologixlinkissue16853 messages
2013-08-24 12:04:14neologixcreate