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

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