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

[Martin v. Loewis]

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