When using a socket._fileobject as stdin or stdout, subprocess.Popen fails:

Traceback (most recent call last):
...
  File "c:\Python25\lib\subprocess.py", line 586, in __init__
    errread, errwrite) = self._get_handles(stdin, stdout, stderr)
  File "c:\Python25\lib\subprocess.py", line 680, in _get_handles
    p2cread = msvcrt.get_osfhandle(stdin.fileno())
IOError: [Errno 9] Bad file descriptor


Enclose are a _simple_ TCPSocket-Server using subprocess.Popen for echoing some text to the socket. On Linux this works, on Windows this fails with the above traceback.

Usage:
1) In one shell start tst_subprocess_socket.py
2) In a second shell start tst_subprocess_socket_client.py
3) On Window, the server will fail and produce the obove traceback.

File Added: tst_subprocess_socket_client.py

This is a known limitation of Windows; unlike
UNIX like systems, it treats sockets and file
descriptors as completely different entities.
I don't think there is anything that Python
can do to hide this difference.

Correct

In Windows file descriptors are handled by the MSVCR library and socket
descriptors by winsock (ws32*). For the same reason you can't use a fd
with select on Windows.

wont fix == Can't fix Windows

"Can't Fix" that is not true. 

I've just fixed this in 2.7 with a trivial change to subprocesss.py, I think it'd work in over versions too.

Note that type shenanigans are already in play in _get_handles, it's looking at the types of the parameters being passed in to decide how to get a hold of the "handle". The socket module makes a duck type of the file object. The fileno() method of the socket object returns a handle not a CRT file descriptor. This is exactly the kind of handle that _get_handles() is looking for.

So all that is needed is one more "if" to the sequence of how to get the "handle" which for a socket object would be just stdin.fileno() etc.

I've just tested this in a fairly complicated remote job queuing software (a commercial product) that has the ability to connect the spooler (on one machine) with an arbitrary server machine (linux, osx and now windows) via a socket. The job is launched with subprocess.Popen and sockets are wired into the stdin,stdout and stderr. Works beautifully now.

I've attached a patch file made with:
$ diff -c subprocess.py.ORIG subprocess.py  > subprocess.py.patch

Apply with:
$ cd  Python-2.7.1/Lib ; patch -p0 < c:/temp/subprocess.py.patch

Cheers,
- James