[Biopython-dev] subprocess and calling application wrappers

[Brad Chapman]

Peter;

[Simplified interface for calling commandline programs]
> Having thought about this for a while, I realised that in almost every
> case I have never cared about the exact return code, just if it is zero
> (success) or not (failure). Therefore the behaviour of the subprocess
> functions check_call (Python 2.5+) and check_output (Python 2.7+)
> seems desirable (you get an exception if the return code is non zero).

This makes good sense.

> That just leaves what to return: stdout and/or stderr. I personally
> have never needed to merge stderr and stdout into a single pipe
> or string - the only use case for this I can think of is to capture the
> output into a file for logging purposes. Generally it makes more sense
> to keep them separate. This leaves the question should we return
> just stdout, or both? Sometimes stderr is useful, so I think both.

Both is also my preference.

> So, in yet-another-branch, I wrote a __call__ implementation which
> raises an exception on non-zero return codes, but otherwise returns
> stdout and stderr as a tuple of two strings:
> 
> http://github.com/peterjc/biopython/commits/app-exec3

Generally the idea and implementation are great. My only specific
suggestion is regarding the default handling of stdout and stderr
when you don't want to capture them. Currently you are eating those
by writing to /dev/null. Would it be clearer to just use the
default, which is to continue to route the programs stdout and
stderr through the main instance? This gives friendly
feedback that the program is running and makes debugging errors
easier, especially if an external program doesn't use error codes
correctly.

Awesome to see this going in,
Brad