I'm not a big fan of the settimeout approach myself (and only did it because it was mentioned as a possible approach).  I think the existing implementations of EINTR retry also suffer from the same issue in which the timeout isn't adjusted per iteration (but that's okay, see below).

The _fileobject explicitly states only to use a blocking socket (i.e. one without a timeout set), so in practice, that shouldn't be a problem.  I'd like to ensure the rest of the calls in that class take the same approach (thus the retryable call function, originally without the settimeout code) as they're a higher level abstraction above recv/send. 

The only other call in socket.py that also qualifies as a higher abstraction is create_connection.   If we could apply the 2.7 patch you created, connect ought to be correct at that point.  All that remains after that would be isolating _retryable_call to _fileobject calls -- sans the settimeout -- which requires a blocking socket anyway. In retrospect, I probably should have just placed that call in _fileobject anyway. 

I think that addresses most of what I'd like to fix.  Of course, I'm happy to go through and weave PEP 475 into the socketmodule.c code entirely, but if the code churn creates too much worry, I think the above is a good medium.