RetroSearch Browse

Fri Mar 16 17:37:04 CET 2007 · https://mail.python.org/pipermail/python-dev/2007-March/072066.html

-> > >> 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-March/072066.html below:

[Python-Dev] deprecate commands.getstatus()