In 2.7, the _handle attribute is a _subprocess_handle object, which automatically calls CloseHandle when deallocated. For example:

    >>> p = subprocess.Popen('python -c "import time; time.sleep(120)"')

CreateProcess returns both the process handle and the thread handle. Python doesn't use the thread handle, so it explicitly closes it by calling ht.Close():

    Breakpoint 0 hit
    KERNELBASE!CloseHandle:
    00007ffb`a32fdf70 4883ec28        sub     rsp,28h
    0:000> kc 5
    Call Site
    KERNELBASE!CloseHandle
    python27!sp_handle_close
    python27!PyCFunction_Call
    python27!call_function
    python27!PyEval_EvalFrameEx
    0:000> g

(IMO, it should skip this step if creationflags contains CREATE_SUSPENDED. The thread handle makes it simpler to call ResumeThread.)

On the other hand, the process handle is deallocated implicitly when it's no longer referenced:

    >>> type(p._handle)
    <type '_subprocess_handle'>
    >>> hex(int(p._handle))
    '0x164L'

    >>> p.terminate()
    >>> del p

    Breakpoint 0 hit
    KERNELBASE!CloseHandle:
    00007ffb`a32fdf70 4883ec28        sub     rsp,28h
    0:000> kc 5
    Call Site
    KERNELBASE!CloseHandle
    python27!sp_handle_dealloc
    python27!dict_dealloc
    python27!subtype_dealloc
    python27!PyDict_DelItem
    0:000> r rcx
    rcx=0000000000000164

If the process handles aren't being closed in your case, then you're probably keeping a reference to the Popen instances.

P.S. A Windows handle is not a "file descriptor". Kernel handles are user-mode references to kernel objects. They aren't "files" unless the object happens to be a File object. A process handle references a kernel Process object.