[Biopython-dev] Biopython wrappers' behavior

[Eric Talevich]

On Fri, May 11, 2012 at 12:08 PM, Wibowo Arindrarto
<w.arindrarto at gmail.com>wrote:

> Hi everyone,
>
> There has been a recent discussion on Github (here:
>
> https://github.com/bow/biopython/commit/b0b1a460149d4a68f76ebde916471628cecfe4e7#-P0
> )
> regarding the way our command line wrappers are supposed to work. It
> started as a question on how to handle incompatible parameters and
> boils down to how much complexity we want to have in our wrappers.
>
> To give you an illustration:
>
> We have wrappers for BLAST, which raise exceptions if two incompatible
> parameters are used at the same time. This mimics BLAST's behavior,
> since it will also show errors if given that same combination of
> parameters sans using our wrapper. However, the way other programs
> handle incompatible parameters are not always the same as BLAST's. For
> example, HMMER doesn't show any errors but nothing still gets run, and
> EMBOSS seems to use the last parameter it sees, ignoring previous
> ones. I have not tested this for all available programs and parameters
> in each suite, but it seems reasonable to extrapolate the behavior to
> the rest of the programs in their respective suite.
>
> The question is, how should our wrappers handle this? Should we:
>
> * Raise errors whenever incompatible parameters are used (as seen in
> BLAST's wrappers)? Or perhaps just give warnings? This is an extra
> layer of complexity, but it would help users figure out if something
> goes unexpected when using our wrappers.
> * Leave it as it is and not worry about incompatible parameters at
> all? Perhaps we could also report a bug / feature request to the
> respective programs' authors and expect their default behavior to
> change?
> * (other ideas...)?
>
> I personally favor mimicking the programs' behavior as close as
> possible. If it gives errors, we should handle it with our code, if
> not then we leave it as it is, even if it results in some unexpected
> behavior, but this is just me. What do you think? How should our
> wrappers handle incompatible parameters?



There are certain motivations that apply to command-line tools but not
Python object-based wrappers. The first thing that comes to mind is the use
of scripts and aliases on the command line, where an existing setting
"--foo" can be reversed/nullified by adding the "--no-foo" later in the
command line.

Examples -- say these are set globally in /etc/profile:

% alias ourwater="water -brief"
% ourwater -nobrief

% export COMMON_BLAST_OPTIONS="-d /opt/db/nr -e 1e-4 --foo"
% blastall -i myseq.fa $COMMON_BLAST_OPTIONS --no-foo


I think EMBOSS handles this situation in the most Unix-friendly way, while
BLAST is being fussy and HMMer is... still in development.

In any case, this situation doesn't apply in Python/Biopython. If we want
to reverse or reset an attribute on an object, we assign a new value to it,
problem solved.

>>> some_cmd = SomeCommandlineWrapper(foo=True)
>>> some_cmd.foo = False

So, I would support these behaviors in general:

1. If conflicting options are specified together in the constructor
(__init__), raise an exception:

>>> SomeCommandlineWrapper(foo=True, nofoo=True)  # kaboom!

2. Where it's possible and intuitive, only use one attribute to specify
boolean behaviors. Instead of having 'foo' and 'nofoo' attributes, just
have 'foo', and let the 'nofoo' switch set that attribute to False. When
building the command line for execution, sort it out again. I'm not sure
about the easiest way to do this with Bio.Applications, but maybe we should
come up with a standard mechanism for it.