[Biopython-dev] subprocess and calling application wrappers

[Peter]

On Fri, Jul 23, 2010 at 12:48 PM, Brad Chapman <chapmanb at 50mail.com> wrote:
> 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.
>

Good.

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

Good.

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

Fair point. Personally I'd either want to capture the output (default) or
completely ignore it (hence the implementation in this branch). Anyone
else want to comment on this aspect?

> Awesome to see this going in,
> Brad

Peter