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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4