> > Why not simply reverse the wait() and read() calls?
>
> I don't think it is sufficient if the user uses more than one pipe. The
> subprocess.communicate() and _communicate() methods are using threads
> (Windows) or select (Unix) when multiple pipes for stdin, stderr and
> stderr are involved.

That is done precisely to *avoid* blocking. I believe the only reason
your example blocks is because you wait before reading -- you should
do it the other way around, do all I/O first and *then* wait for the
process to exit.

> The only safe way with multiple pipes is communicate([input]) unless the
> process returns *lots* of data. The subprocess module is buffering the
> data in memory if the user uses PIPE or STDIN.

I disagree. I don't believe it will block unless you make the mistake
of waiting for the process first.

> The subprocess module also contains a XXX comment in the unix version of
> _communicate()
>
>    # XXX Rewrite these to use non-blocking I/O on the
>    # file objects; they are no longer using C stdio!
>
> Should I create another bug entry for it?

No, we have too many bug entries already.