> When I try this with a UDP socket, the thread calling shutdown
> raises an OS Error (transport end point not connected).

Which is normal, since UDP sockets aren't connected.

> In contrast, sock.close does not cause the blocked thread to unblock.
>  (This is the same for both TCP and UDP sockets.)

Which is normal, since you're not supposed to do this.

> I suspect Python is just exposing the underlying C behavior of
> shutdown and recvfrom.  I'd test it in C, but I'm not fluent in
> writing multi-threaded code in C.

You'd get exactly the same behavior.

> It would be nice if the recvfrom thread could raise some kind of
> exception, rather than appearing to return successfully.  It might
> also be worth reporting this bug upstream (where ever upstream is for
> recvfrom).  I'm running Python 3.3.1 on Linux.

This isn't a bug: you're not using using the BSD socket API correctly. You can try reporting this "bug" upstream (i.e. to the kernel mailing list): it'll be an interesting experience :-)

> The Python socket docs could mention that to unblock a reading thread, 
> sockets should be shutdown, not closed.  This might be implied in the
> current docs, but it could be made explicit.  See:

If we start documenting any possible misuse of our exposed API, the documentation will get *really* large :-)

Really, the problem is simply that you're not using the socket API as you should.

Iy you want do unblock your thread doing a recvfrom(), you have several options:
- send a datagram to the socket address from another thread
- use a timeout on the socket, and periodically check a termination flag
- use select()/poll() to multiplex between this socket and the read-end of a pipe: when you want to shutdown, simply write some data to the pipe: this will wake up select()/poll(), and you'll know your thread can exit

Closing as invalid.