-> > >> 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...)? 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. 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? 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. cheers, --titus [0] As per GvR, http://mail.python.org/pipermail/python-dev/2007-March/071926.html _______________________________________________ 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