[Python-Dev] PEP 324: popen5 - New POSIX process module

Moore, Paul Paul.Moore at atosorigin.com
Tue Jan 6 11:10:25 EST 2004

From: John Williams
> - Would you consider adding an example of how to chain processes
> together into a pipeline? You say this is possible, and I'm assuming
> that's what the PIPE constant is for, but I'd like to see it written out
> to make sure I'm understanding it correctly.

There's actually an example in the source code. Looking at it, I have come
to the conclusion that I don't like PIPE, but I can't see an obviously
better answer.

The example from the code is:

    p1 = Popen(["dmesg"], stdout=PIPE)
    p2 = Popen(["grep", "hda"], stdin=p1.fromchild)
    result = p2.communicate()[0]

Some things immediately spring from this:

1. stdout=PIPE doesn't feel like it adds anything. It's "obvious" that
   I want a pipe. But of course there's no way the code realises that
   unless I say so.
2. fromchild doesn't look too nice. I'd prefer to use "stdin=p1.stdout".
3. communicate() doesn't really describe what it does very well.

As far as PIPE goes, the issue is that there are (to me) two, almost
equally common, options - to simply inherit the parent's stdXXX (like
os.system does) and to set up pipes to (some or all of) the child's stdXXX,
which the parent then talks to.

PIPE says to set up a pipe, where the default is to inherit.

I'd like to see a better option, but I can't immediately think of one. This
cries out for a "just do what I mean" option :-)

Maybe inverting the sense of the argument, and saying pipe=STDOUT, or in
the case of multiple pipes, pipe=(STDIN, STDOUT), is better. What do
people think? But remember that *all* of these look worse if you don't use
from...import style: stdout=popen5.PIPE or pipe=popen5.STDOUT.

Part of me wonders whether the creation of the child process should be
split out of the constructor, so that we do p1 = Popen(...); p1.start().
Then setting up pipes could happen between the two. But I can't think of a
syntax I like for setting up pipes even then, and I see no other advantage
to a separate start() method.

I'll see what this feels like when I have practical experience implementing
the Windows version under my belt...


PS If this becomes a design discussion, is python-dev (or even python-list)
   appropriate? Would it be better to set up a SIG for this, much like
   optparse had the getopt-sig for a while?

More information about the Python-Dev mailing list