[Python-Dev] PEP 324: popen5 - New POSIX process module
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
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
> - 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"  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
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,
> - 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
More information about the Python-Dev