hi,

  first, background:

  OS: OpenBSD-current/i386
  Python version: 2.3.4

   example script:

import socket

socket.setdefaulttimeout(30)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 9999))

   where nothing is listening on 9999 (ECONNREFUSED
should be returned).
   when ran it i get:

Traceback (most recent call last):
  File "bug.py", line 8, in ?
    s.connect(('127.0.0.1', 9999))
  File "<string>", line 1, in connect
socket.error: (22, 'Invalid argument')

  this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
  this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux!!!!).
  please contact me if you need further details,
although i find this very clear.
  thanks,

  f.-

Logged In: YES 
user_id=50493

maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.

f.-

Logged In: YES 
user_id=50493

any news? this may be a problem in other *BSDs as well..

Logged In: YES 
user_id=50493

just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(

Logged In: YES 
user_id=33168

Can you provide a patch that you believe corrects this problem?

Logged In: YES 
user_id=50493

patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.

Logged In: YES 
user_id=202246

I can confirm the bug running Python 2.4.2 on Mac OS X
10.4.5 (PPC). However, the patch doesn't seem to resolve the
issue. Now I get the following traceback when running the
posted script:

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<string>", line 1, in connect
socket.error: (36, 'Operation now in progress')

Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

Logged In: YES 
user_id=11375

I can confirm the bug on MacOS X, and the failure of the
patch to fix it.

I think the logic of the patch is wrong; it saves errno in
save_errno when errno==EINPROGRESS, does a getsockopt(), and
then resets errno to save_errno, which we know is
EINPROGRESS.  I think the correct action is to do 'errno =
<result of the getsockopt>".

Revised patch attached; it produces the correct result on OS X.

Logged In: YES 
user_id=11375

Deleting broken patches; attaching a correct version against
2.5 trunk.

Logged In: YES 
user_id=33168

Andrew, I'm ok with this patch, but not enthusiastic for
2.5.  It might be better to wait for 2.5.1 in order to give
this more time to settle.  I agree that this change *should*
be correct, but who knows if it will break some other
platform(s).  I leave it to you whether to apply for 2.5 or
2.5.1.  It would be good to actually test this condition too.

Logged In: YES 
user_id=11375

I agree -- this sort of Unix-platform-specific bugfix is
always risky.  It would have been better if this patch could
have been committed in one of the alphas.

I'll put this bug in the Python 2.6 group and commit it
after 2.5final is released (perhaps it can also go on the
release25-maint branch at that time).

Applied to 2.6 trunk in rev. 60101 (at long last!).  Thanks for your patch!