In IDLE, PythonWin or other non-console interactive Python under Windows:

>>> from subprocess import *
>>> Popen('cmd', stdout=PIPE)

Traceback (most recent call last):
  File "<pyshell#11>", line 1, in -toplevel-
    Popen('', stdout=PIPE)
  File "C:\python24\lib\subprocess.py", line 533, in __init__
    (p2cread, p2cwrite,
  File "C:\python24\lib\subprocess.py", line 593, in _get_handles
    p2cread = self._make_inheritable(p2cread)
  File "C:\python24\lib\subprocess.py", line 634, in _make_inheritable
    DUPLICATE_SAME_ACCESS)
TypeError: an integer is required

The same command in a console windows is successful.

Why it happens: 
subprocess assumes that GetStdHandle always succeeds but when there is no console it returns None. DuplicateHandle then complains about getting a non-integer. This problem does not happen when redirecting all three standard handles.

Solution:
Replace None with -1 (INVALID_HANDLE_VALUE) in _make_inheritable.

Patch attached.

This patch looks very interesting. However, it feels a little bit strange to call DuplicateHandle with a handle of -1. Is this really allowed? What will DuplicateHandle return in this case? INVALID_HANDLE_VALUE? In that case, isn't it better to return INVALID_HANDLE_VALUE directly? 

If you duplicate INVALID_HANDLE_VALUE you get a new valid handle to nothing :-) I guess the code really should not rely on this undocumented behavior. The reason I didn't return INVALID_HANDLE_VALUE directly is because DuplicateHandle returns a _subprocess_handle object, not an int. It's expected to have a .Close() method elsewhere in the code.

Because of subtle difference between in the behavior of the _subprocess and win32api implementations of GetStdHandle in this case solving this issue this gets quite messy!
File Added: subprocess-noconsole2.patch

Oops. The new patch does not solve it in all cases in the win32api version, either...

This the suggested patches are not ready for commit, I'm moving this issue to "bugs" instead. 

Duplicate of 1124861.