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

Martin v. Loewis martin at v.loewis.de
Sat Jan 3 16:50:24 EST 2004

Peter Åstrand wrote:

This PEP describes a new module for starting and communicating with processes on POSIX systems.

I see many aspects in this PEP that improve the existing implementation without changing the interface. I would suggest that you try to enhance the existing API (making changes to its semantics where reasonable), instead of coming up with a completely new module.

With that approach, existing applications could use these features with no or little change.

- One "unified" module provides all functionality from previous functions.

I doubt this is a good thing. Different applications have different needs - having different API for them is reasonable.

- Cross-process exceptions: Exceptions happening in the child before the new process has started to execute are re-raised in the parent. This means that it's easy to handle exec() failures, for example. With popen2, for example, it's impossible to detect if the execution failed.

This is a bug in popen2, IMO. Fixing it is a good thing, but does not require a new module.

- A hook for executing custom code between fork and exec. This can be used for, for example, changing uid.

Such a hook could be merged as a keyword argument into the existing API.

- No implicit call of /bin/sh. This means that there is no need for escaping dangerous shell meta characters.

This could be an option to the existing API. Make sure it works on all systems, though.

- All combinations of file descriptor redirection is possible. For example, the "python-dialog" [2] needs to spawn a process and redirect stderr, but not stdout. This is not possible with current functions, without using temporary files.

Sounds like a new function on the popen2 module.

- With popen5, it's possible to control if all open file descriptors should be closed before the new program is executed.

This should be an option on the existing API.

- Support for connecting several subprocesses (shell "pipe").

Isn't this available already, as the shell supports pipe creation, anyway?

- Universal newline support.

This should be merged into the existing code.

- A communicate() method, which makes it easy to send stdin data and read stdout and stderr data, without risking deadlocks. Most people are aware of the flow control issues involved with child process communication, but not all have the patience or skills to write a fully correct and deadlock-free select loop.

Isn't asyncore supposed to simplify that?

So in short, I'm -1 on creating a new module, but +1 on merging most of these features into the existing code base - they are good features.

Regards, Martin

More information about the Python-Dev mailing list