On 28 January 2015 at 00:36, Nick Coghlan firstname.lastname@example.org wrote:
I'm with Greg here - the proposed "run()" API sounds like a nice improvement to me, but I don't think it makes sense to deprecate the existing use case specific variants. In particular, check_call() and check_output() aren't easily replaced with equivalent expressions based on run() since you need to make a separate call to cp.check_returncode().
Good point. Perhaps it would be more useful for run() to take a kwarg check_returncode, which if True would cause it to raise on a non-zero exit code? That way, any of the function trio could be replaced by use of run().
Note that in Python 3, if universal_newlines=True is given, the output
a str, not bytes.
Ugh, yes. I would follow that for consistency, though I'd love to come up with a way to clean that up too. The fact that 'decode the output' is spelled 'universal_newlines' is one of my least favourite things about subprocess.
We need to keep those. They are too widely used and are the long term stable API for 2.7. They are useful for many simple cases which they were designed for.
Agreed that this seems like a nice improvement, but that we need to keep
old APIs around probably forever.
Agreed. I would however like to de-emphasise them in the docs.
It seems like there's some level of interest in this; shall I work on a patch?