[Biopython-dev] Biopython wrappers' behavior

[Wibowo Arindrarto]

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

Hi Eric,

Thanks for the explanation! It never occured to me we should consider
custom command-line aliases as well, but that makes sense now.

For your first point, there's already an incompatibility-checking
mechanism implemented in the Bio.Blast.Applications module. It's
currently tied-up to Bio.Blast.Applications's _validate method, but it
seems doable to generalize this into a method of
Bio.Application.AbstractCommandline, so it's available to the rest of
the command line wrappers (EMBOSS wrappers being some of them).

As per your second point, I can imagine three general ways to do this
(on top of my head):

1. Implement a method to override one parameter setting with its
opposing parameter in AbstractCommandline. This is perhaps similar to
Bio.Blast.Application's _validate_incompatibilities method, only
instead of raising an exception it deletes one of the parameters.

2. Implement a new _AbstractParameter subclass that can handle two
different incompatible parameters (this is perhaps too complicated)

3. Implement an incompatibility checking mechanism in
AbstractCommandline.__str__, to define parameters that can override
its pair (e.g. foo and nofoo). This will keep the opposing parameters
stored as the object attribute (so a __repr__ will reveal them both),
but it won't get passed on to the console as the __call__ method
relies on __str__.


Bow