On Sat, Aug 24, 2013 at 5:04 AM, Charles-François Natali
<report@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.