Just for the record, I was initially in favor of recomputing the
timeout and retrying upon EINTR, but Guido prefers to return empty
lists, and since that's a better compromise than the current situation
(I've seen *many* people complaining on EINTR popping-up at random
points in the code, including myself), I went ahead and implemented
it.

AFAICT, an early return for calls such as poll()/epoll() etc is
something which is definitely acceptable: if you have a look at e.g.
Tornado, Twisted & Co, they all return empty lists on EINTR.

> I've always had the implicit understanding that if I use an *infinite* timeout then > the call will not timeout.

Well, I've always assumed that time.sleep(n) would sleep n seconds, but:
"""
static int
floatsleep(double secs)
[...]
    Py_BEGIN_ALLOW_THREADS
    err = select(0, (fd_set *)0, (fd_set *)0, (fd_set *)0, &t);
    Py_END_ALLOW_THREADS
    if (err != 0) {
#ifdef EINTR
        if (errno == EINTR) {
            if (PyErr_CheckSignals())
                return -1;
        }
        else
#endif
        {
            PyErr_SetFromErrno(PyExc_IOError);
            return -1;
        }
    }
[...]
"""

So really, I'm like Gregory: I don't care which solution we chose, but
I just don't want to have to let the user handle EINTR.