FYI - use the changes made in http://bugs.python.org/issue12268 as a guide for how to deal with EINTR properly at the C level.  See the _PyIO_trap_eintr() function for example.

See also _eintr_retry_call() in Lib/subprocess.py.

FWIW, there are times when we *want* the interrupted system call to return control to Python rather than retrying the call.  If someone is making a Python equivalent of the low level system call such as select() or poll(), the EINTR should be exposed for Python code to handle.

Things like time.sleep() are documented as sleeping for less time when a signal has arrived even though an exception may not be raised. People have written code which depends on this behavior so adding an EINTR retry for the remaining sleep time would break some programs.

Getting an EINTR errno does *not* mean you can simply retry the system calls with the exact same arguments.  ie: If you did that with the select() call within time.sleep it'd be trivial to make the process sleep forever by sending it signals with a frequency less than the sleep time.