On Sun, Apr 2, 2017 at 4:08 PM, Terry Reedy <tjre...@udel.edu> wrote: > Both are subclasses of OSError but mean different things. TimeoutError > means that something in 'your system' did not respond. Socket.timeout means > that a foreign system did not respond. (I am leaving out a local socket > connection.) The latter can only happen with a socket call with timeouts > enabled. If it is possible for TimeoutError to also occur with a > timeout-enabled socket call, then one might very well want to only catch one > or catch them separately and respond differently.
I don't necessarily disagree with the conclusion, but I'm pretty sure this is rationale is wrong: connect / recv / etc. can return ETIMEDOUT if the peer is non-responsive and some internal operating-system-specific timeout expires (see e.g. [1], or the TCP_USER_TIMEOUT socket option). So both TimeoutError and socket.timeout can indicate a non-responsive remote system, and the actual difference is in who implements the timeout: socket.timeout means that the timeout implemented by the Python interpreter and controlled by socket.settimeout() expired; TimeoutError means that the timeout implemented by the kernel expired. You can also get TimeoutError in other odd places like the pthread synchronization functions that take a timeout, or when working with POSIX message queues for IPC. These do describe stuff that's on the same system timing out, but since these APIs aren't exposed by Python I'm not actually sure if it's possible in practice to get a TimeoutError except with a socket talking to a non-responsive peer. -n [1] https://stackoverflow.com/questions/8471577/linux-tcp-connect-failure-with-etimedout -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
