test_socket fails randomly in about 1 of 50 iterations (MacOS X 10.5.5 
intel):

$ for ((;;)); do DYLD_FRAMEWORK_PATH=/Users/martina/Downloads/Python-
3.0rc3: ./python.exe -E -bb ./Lib/test/regrtest.py -l test_socket;done
test_socket
1 test OK.

...

test_socket
test test_socket failed -- Traceback (most recent call last):
  File "/Users/martina/Downloads/Python-3.0rc3/Lib/test/test_socket.py", 
line 121, in _tearDown
    self.fail(msg)
AssertionError: [Errno 57] Socket is not connected

1 test failed:
    test_socket
test_socket
1 test OK.

...

Thanks for the report.  I can reproduce this both on the py3k branch and the trunk.  It looks as though there's a race condition 
in the testShutDown/_testShutDown pair of methods in SocketConnectedTest.  If you add the line

time.sleep(0.01)

to the middle of the _testShutDown method in test_socket.py (between the self.serv_conn.send() and the self.serv_conn.shutdown), 
you'll probably find that this random occasional failure becomes a 99.9% reliable failure.

As far as I can tell, this is just a bug in test_socket itself, rather than a problem with the socket module.  I also can't see 
any reason why it should be Mac specific, but I don't have anything else handy to test on right now.

Suggested fix:  don't let testShutDown exit until after _testShutdown has executed the shutdown method.  Use a threading Event to 
make this work.  The attached patch (against the trunk) appears to fix the problem for me.  Martina, if you're in a position to 
test the patch, feedback would be welcome.

It would be good if someone could review this for sanity;  I'm a complete novice when it comes to threading (and sockets, for that 
matter).

Hmm.  I take it back:  this *does* appear to be OS X specific.
I've attached a small (17-line) example that fails with
the Errno 57 error on OS X, but passes on the Linux machines I tested.

In this example, it appears that when 'conn.close()' is called by the 
server, the client socket 'cli' is automatically disconnected, hence
the shutdown failure.  On Linux that doesn't happen.

Can anyone shed any light on this, and/or suggest what should be done?

Found a better (one-line) fix.  Fixed in the trunk in r68611.
Will port to 2.6, 3.0, 3.1.

Fixed in 2.6, 3.0, 3.1.