2013/8/31 Guido van Rossum <report@bugs.python.org>:
> But still I agree with Giampaolo that the decorator doesn't feel
> right. It's like a try/except around the entire body of your function,
> which is usually a code smell (even though I realize the exception it
> catches can only be raised by the syscall). Please go back to the
> explicit try/except returning [].

Well, I'll change it, but:
We have to change the select() docstring to "Wait until some
registered file objects become ready, or for *at most* timeout
seconds"

All user code that wants to handle EINTR or correct timeout (which
should be "all user code" in a perfect world) will have to wrap the
call to select() inside a loop equivalent to this decorator, and I
personally like the a rule of "never let the user do what the library
can do for him".
This includes for example multiprocessing and telnetlib which
currently implement this EINTR handling loop with timeout computation,
see e.g.:
http://hg.python.org/cpython/file/acc7439b1406/Lib/telnetlib.py#l297

And other places in the stdlib either don't handle EINTR properly, or
don't re-compute timeout (see e.g. http://bugs.python.org/issue12338).

Also, I don't really see the problem with retrying upon EINTR, since:
- the signal handler will be called right away anyway
- in case where the select() is a part of an event loop, the event
loop registers a wakup file descriptor with the selector, which means
that upon interesting signal delivery, the select() call will return
to the schedulor

So in short, I don't see how that could be a nuisance, but I can
certainly see how this could trick user code into raising spurious
timeout-related errors, or be much more complicated than it ought to
be (the above telnetlib example is IMO a great example of why EINTR
and timeout computation should be handled at the selector level).