[Biopython-dev] Biopython wrappers' behavior

[Eric Talevich]

On Mon, May 14, 2012 at 3:29 PM, Wibowo Arindrarto
<w.arindrarto at gmail.com>wrote:

> > 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__.
>
>
Here's a fourth to consider, similar to your #1 (not to disagree with any
of your suggestions): add an "_AntiSwitch" class to Bio.Applications, which
includes a reference or string name of the attribute/parameter it
nullifies. Would that be easier to specify when writing the application
wrapper?