[Biopython-dev] ApplicationResult and generic_run obsolete?

Peter biopython at maubp.freeserve.co.uk
Mon Jul 6 21:06:54 UTC 2009

On Mon, Jul 6, 2009 at 8:35 PM, Bartek
Wilczynski<bartek at rezolwenta.eu.org> wrote:
> I'm fine with deprecating ApplicationReslut.
>> Personally when running a sub-process I have either wanted the stdout
>> (and stderr) handles, OR the return code (and I don't have about
>> stdout and stderr). I can't think of a situation off hand where I
>> needed both. So for me, the Bio.Application.generic_run function isn't
>> very helpful.
> Well, I don't have too much experience with writing application wrappers,
> but I can easily think of the scenario when I first check whether the program
> returned the "right" error code and then if it's fine I would process
> the stdout.

True - but in practice I usually find it more productive to switch to
the command line prompt and explore the failure there (rather
than trying to diagnose things from within Python). I would be
content for the script to tell me a command line failed with an
error return code (and give me the command line string and
the return code).

>> If we want to deprecate Bio.Application.generic_run (in order to
>> deprecate Bio.Application.ApplicationResult), then do we need a
>> replacement? Or replacements?
>> (b) Returns the return code (integer) plus the stdout and stderr
>> (which would have to be StringIO handles, with the data in memory).
>> This would be a direct replacement for the current
>> Bio.Application.generic_run function.
> That sounds like a good replacement.

Of the three examples I put forward, (b) certainly seemed most
useful. Any other ideas?

>> However, I'm tempted to say Biopython shouldn't be duplicating basic
>> Python functionality, like wrapping the subprocess module in helper
>> functions for typical situations. Instead we should just document
>> using the current recommend Python best practice (which I believe to
>> be use the subprocess module). The downside is that using subprocess
>> is a bit tricky for novices.
> I don't have strong feelings about that, but my personal experience is
> that it helps to have some infrastructure which (even if providing
> somewhat superfluous API layer over the bare python libs), especially
> for people who may have limited experience with different platforms.
> I, for one, would find it useful if biopython provided a simple
> classes which allowed people to write cross-platform wrappers
> for command line tools.

Do you feel option (b) above would fit that criteria?


More information about the Biopython-dev mailing list