[Python-Dev] PEP 324: popen5 - New POSIX process module (original) (raw)

Peter Åstrand astrand at lysator.liu.se
Wed Jan 7 10:21:15 EST 2004

This PEP looks fantastic to me; I've often wanted a better set of primitives for working with external processes, and your PEP has just about everything I've ever wanted.

Great :-)

I do have some minor nits to pick, though:

- The preexecargs argument is extraneous considering how easy it is to use a lambda construct to bind arguments to a function. Consider: Popen(..., preexecfn=foo, preexecargs=(bar,baz)) vs. Popen(..., preexecfn=lambda: foo(bar,baz))

Nice. The only drawback with this approach that I can think of right now is that this will be hard for newbies to understand, but if we give a few examples in the doc this is probably not a problem.

I'll make this change, unless I hear protests.

- Rather than passing argv0 as a named argument, what about passing in the program to execute instead? It would simplify code like this:

Popen(childprogram, *childargs[1:], argv0=childargs[0]) into this Popen(*childargs, program=childprogram) Of course I'm not suggesting you change the default behavior of taking argv0 and the program to execute from the first positional argument.

I don't understand exactly what you mean here; could you provide a working example?

- The defaults for closefds and universalnewlines should be False rather than 0; this would make it clear from reading the synopsis that these arguments are boolean-valued.

Yes, I've fixed this now.

- The poll() method and returncode attribute aren't both needed. I like returncode's semantics better since it gives more information and it avoids using -1 as a magic number.

Well, as I described in another mail, it's actually a big advantage to provide both a returncode attribute and an unmodified status value, since it's makes it easy to migrate from the "old" API. Perhaps we'll need to make some changes to the poll() method wrt Windows, though.

- Rather than raising a PopenException for incorrect arguments, I would think that raising ValueError or TypeError would be more in line with users' expectations.

Sounds good to me. Anyone else has comments?

- How does this communicate() method interact with I/O redirection?

Now I'm lost again. Which kind of redirection are you thinking about?

/Peter

More information about the Python-Dev mailing list