anatoly techtonik <techto...@gmail.com> added the comment: After rewriting my reply several times I've noticed my mistake, but it took more time to understand the problem than could be expected for a language that we all would like to see as easy and intuitive as possible. That why I still would like to see this bugreport reopened. At first it seemed that adding missing details to documentation would be enough, but now I see that this problem can be deeper.
The problem: As far as I informed, the socket module is the only way to wait for service on server:139 to appear. socket documentation doesn't reflect that will happen if network server is down (server is not network adapter). Analysis: In this specific timeout condition when server is offline socket.connect can throw two different errors: "socket.error: (10060, 'Operation timed out')" and "socket.timeout: timed out" Which one will fire and should be catched depends on the visible timeout settings for the socket and on invisible timeout value of underlying network library. Whichever occurs first - wins. For example, this code will warn you about network timeout: import socket s = socket.socket() s.settimeout(12.0) try: s.connect(("192.168.1.2", 139)) except socket.timeout: print "connect timeout" But this one won't: import socket s = socket.socket() s.settimeout(120.0) try: s.connect(("192.168.1.2", 139)) except socket.timeout: print "connect timeout" So, for reliable socket programming you should catch both. Solution: If there is a possibility for a socket to timeout when it is not expected then at least it should be documented. Alternative solution would be to document and merge socket.error: 10060 into socket.timeout exception. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5293> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com