On 28 January 2015 at 00:36, Nick Coghlan <ncoghlan@gmail.com> 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().

Barry:
> Note that in Python 3, if universal_newlines=True is given, the output will be
> 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 the
> 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?

Thanks,
Thomas