This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt, vstinner
Date 2013-08-26.19:49:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJJJFBg+=87Dh9mMHUzDSV7quHUZL51hwVZCM-F9VFQeJA@mail.gmail.com>
In-reply-to <CAH_1eM3-7x_i3vJtF8ZNf5ia0hCBBUU6MCq4W9r2h1UH8n+KeA@mail.gmail.com>
Content
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.
History
Date User Action Args
2013-08-26 19:49:17gvanrossumsetrecipients: + gvanrossum, pitrou, vstinner, giampaolo.rodola, christian.heimes, meador.inge, neologix, rosslagerwall, sbt, felipecruz
2013-08-26 19:49:17gvanrossumlinkissue16853 messages
2013-08-26 19:49:16gvanrossumcreate