STINNER Victor added the comment: > On POSIX systems using os.times()[4] rather than an absolute time.time(),
This is just wrong. os.times() doesn't use seconds, but an "CPU time" which is unrelated. socket.settimeout() uses seconds. By the way, as I wrote before: using the system clock here may introduce bugs when the system clock goes forward to backward, but Python 2.7 doesn't have a monotonic clock :-( That's another reason why I didn't want to fix Python 2.7 or 3.4. > (For UDP it might be a valid thing to do but it still has an odd smell to it) I'm concerned by backward compatibility. Trivial changes was made in Python 2.7 and then came back as regressions because it broke several applications. See recent discussions on this topic on python-dev. Handling EINTR and recompute the timeout is not a trivial changes, some applications rely heavily on the current behaviour of sockets. Network servers using Twisted, eventlet and other libraries. When we say "threads", also think about greenthreads which are used in eventlet to handle sockets. > Some things in 2.7 related to EINTR have already been fixed in the past few > years such as data loss in readline() and IIRC writelines(). Correctness > isn't a feature. readline()/writelines() don't have a timeout, so it was easier to handle EINTR there. > Do you consider it an API change to prevent an error that nobody relies on or > even expects (as PEP 475 notes) and virtually no code is written to properly > handle when it _does_ happen? For your information, some people already contacted me because their application behaves differently on Python 3.5 (with the PEP 475). Well, it was easy to modify their code to not rely on EINTR, but it means that "Applications relying on the fact that system calls are interrupted with InterruptedError will hang" exists in the wild. While it's acceptable to change such thing in Python 3.5, a new major version, I asked if it's acceptable for a minor version. By the way, Python 3.5 is not released yet, so we can expect more feedback on PEP 475 changes when Python 3.5 will be released (other regressions in applications?). > Please don't WONTFIX this issue, I intend to get safe fixes in. I suggest WONTFIX for Python 2.7, this issue is *already* fixed in Python 3.5. Come on, in 2015 it's time to upgrade to Python 3! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23863> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
