Logged In: YES 
user_id=31435

I can confirm that Guido certainly didn't intend for a refused 
connection to wait for the timeout on Windows.  A problem is 
that the attempt to connect here isn't returning 
WSAECONNREFUSED on Windows, it's returning 
WSAEWOULDBLOCK.

If you set the default timeout back to None, the attempt to 
connect *does* return WSAECONNREFUSED on Windows.  
But for whatever reason, the Windows implementation of 
sockets appears to turn that into WSAEWOULDBLOCK if (and 
only if) the socket is in non-blocking mode.

The problem then is trying to guess some way to figure out 
whether WSAEWOULDBLOCK on a Windows non-blocking 
socket connect *means* "there's no chance this will ever 
succeed" or "I can't connect immediately, but maybe I can 
later".  It appears to mean both things <grrrrr>.

Note this:

>>> s = socket.socket()
>>> s.setblocking(0)
>>> s.connect(("www.python.org", 9999))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in connect
socket.error: (10035, 'The socket operation could not 
complete without blocking')

Now at this point, the code essentially does this:

>>> select.select([], [s], [], 10.0)
([], [], [])
>>>

and select waits 10 seconds before returning.

However, if we do this instead (I'm adding a non-
empty "error/exception" list argument):

>>> select.select([], [s], [s], 10.0)
([], [], [<socket._socketobject object at 0x008EBA80>])
>>>

then it returns immediately, with the socket in the exception 
list.

So that's a clue.  How can we tell *what* error occurred?  
Hmm.  For the exception list, MS select docs say a socket will 
appear there when:

"If processing a connect call (nonblocking), connection 
attempt failed "

So the behavior so far matches the docs.  Later it says

"""
If a socket is processing a connect call (nonblocking), failure 
of the connect attempt is indicated in exceptfds (application 
must then call getsockopt SO_ERROR to determine the error 
value to describe why the failure occurred). This document 
does not define which other errors will be included.
"""

So there you go <wink>:  we have to add the socket to the 
select call's exception set.  Then the select call won't wait 
forever.  When it comes back, and there is an exception, we 
have to call getsockopt() with SO_ERROR to determine the 
cause.