On 3/16/07, Titus Brown <[EMAIL PROTECTED]> wrote: > -> > >> What about reimplementing commands.* using subprocess? Or providing a > -> > >> commands.*-compatible interface in the subprocess module? > > OK, so as I understand it, the next step would be for me to provide a > patch implementing this, right? Or is this PEP-required (please no...)?
No pep. > What do people think of this basic interface? > > (status, output) = subprocess.get_status_output(cmd) > > output = subprocess.get_output(cmd) > > Here 'status' is the 'returncode' from subprocess.Popen, and 'output' > would be the combined stdout/stderr. 'commands.getstatus' would be > removed entirely [0]. > > This mimics 'commands' fairly closely, while adhering to PEP 8 > guidelines; it's a simple API; and it should be dead easy to implement. Right. Does it also match the style of the API provided by the subprocess module? > It will also have the various advantages people have mentioned: > > * better error trapping; > * better post-fork behavior; > * multi-platform support; > > If this sort of thing goes in, I guess commands.* would then be > deprecated with a note saying "go look at these similar commands in > subprocess", right? Yes. Another intermediate step might be to rewrite the commands module to call the new APIs in the subprocess module. > An additional function that I would personally like is: > > (status, output, errout) = subprocess.get_status_output_err(cmd) > > although the name is hideous. I'd like to change 'get_status_output' > to return a triple, but I'm not sure how big a change that would be > relative to the expected behavior from the ancestral commands function. Call it get_status_output_errors and you have my blessings. If at all possible, get_status_output should *not* just concatenate the output and errors from this API, but attempt to really *merge* the stdout and stderr stream so that if they are interleaved they come out in the right order. That's what the old getstatusoutput() did by putting '2>&1' around the command. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com