This bug was fixed in Python 2.3 but has resurfaced in 
Python 2.4

The original bug report can be found at: 
https://sourceforge.net/tracker/?
func=detail&atid=105470&aid=673797&group_id=5470

The method urlopen both in urllib and in urllib2 crashes 
if socket.setdefaulttimeout has been called. Below is a 
cut and paste when using the function in urllib.


>>> import socket
>>> socket.setdefaulttimeout(30.0)
>>> import urllib
>>> urllib.urlopen('https://members.tufts-
health.com/memindex.html')
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "C:\Python24\lib\urllib.py", line 77, in urlopen
    return opener.open(url)
  File "C:\Python24\lib\urllib.py", line 180, in open
    return getattr(self, name)(url)
  File "C:\Python24\lib\urllib.py", line 374, in open_https
    h.endheaders()
  File "C:\Python24\lib\httplib.py", line 794, in 
endheaders
    self._send_output()
  File "C:\Python24\lib\httplib.py", line 675, in 
_send_output
    self.send(msg)
  File "C:\Python24\lib\httplib.py", line 642, in send
    self.connect()
  File "C:\Python24\lib\httplib.py", line 1069, in connect
    ssl = socket.ssl(sock, self.key_file, self.cert_file)
  File "C:\Python24\lib\socket.py", line 74, in ssl
    return _realssl(sock, keyfile, certfile)
IOError: [Errno socket error] (2, 'The operation did not 
complete (read)')

Thanks a ton!

Logged In: YES 
user_id=1163510

having same issue here, using imaplib thru ssl :/

>>> import socket
>>> socket.setdefaulttimeout(10)
>>> i = imaplib.IMAP4_SSL('mail.xxxx.com')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/imaplib.py", line 1101, in __init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib/python2.4/imaplib.py", line 181, in __init__
    self.welcome = self._get_response()
  File "/usr/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/lib/python2.4/imaplib.py", line 969, in _get_line
    line = self.readline()
  File "/usr/lib/python2.4/imaplib.py", line 1136, in readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out

so i can't get timeouts with ssl in imap :/

Logged In: YES 
user_id=1131890

Same problem here with Python 2.4 (#1, Jan 13 2005,
20:34:41) on SuSE Linux 9.2 (i586) and imaplib. Here is a
minimal piece of code that fails (substitute a valid IMAP
server accepting SSL connections):

=== start code snippet ===
import imaplib, socket
socket.setdefaulttimeout(10.0)
imaplib.IMAP4_SSL("imap.whatever.invalid")
=== end code snippet ===

This fails with the following traceback:
=== start traceback ===
Traceback (most recent call last):
  File "./imap_bug.py", line 3, in ?
    imaplib.IMAP4_SSL("imap.whatever.invalid")
  File "/usr/local/lib/python2.4/imaplib.py", line 1101, in
__init__
    IMAP4.__init__(self, host, port)
  File "/usr/local/lib/python2.4/imaplib.py", line 181, in
__init__
    self.welcome = self._get_response()
  File "/usr/local/lib/python2.4/imaplib.py", line 876, in
_get_response
    resp = self._get_line()
  File "/usr/local/lib/python2.4/imaplib.py", line 969, in
_get_line
    line = self.readline()
  File "/usr/local/lib/python2.4/imaplib.py", line 1135, in
readline
    char = self.sslobj.read(1)
socket.sslerror: The read operation timed out
=== end traceback ===

Remove the socket.setdefaulttimeout call and it works properly.
The problem is not due to a slow network connection or
overloaded server -- the script fails for all kinds of
timeouts (1, 10, 100 seconds), but without a timeout the
response is near-instantaneous.

Logged In: YES 
user_id=34209

It seems this was specific to Windows (I was unable to
reproduce it on any version of Python on my UNIX machines),
but it also seems it's fixed in Python 2.5a2 (at least) -- I
can reproduce it with Python 2.4 on Windows XP, but not in
2.5a2. I was unable to identify an obvious fix from the
checkin messages, though (the only likely candidate is a
checkin from before 2.4.0 was released, which claims to fix
the same thing) so backporting to a possible new 2.4 release
is not likely.

Tentatively closing this as fixed. Please pipe up if it
isn't fixed for you, in 2.5a2 or later releases.

Logged In: YES 
user_id=1131890

As I noted in my comment, the problem occurred on Linux, too.
However, it has disappeared in 2.5a2, thanks!