[Biopython-dev] Properties names in command line wrappers

[Brad Chapman]

Hi Peter;
Nice to have you back. Hope you had a relaxing few days away.

> I updated the patch on Bug 2822 to cover all the Bio.Application
> command line wrapper subclasses, and included __repr__ support.
> However, that has raised a real example of a parameter where the
> current "human readable" name is not a valid python identifier ("in",
> for "-in" in Muscle).  I think the pragmatic solution is to add a
> sensible alternative which we can use for the property and keyword
> argument name (e.g. "input" in this case) while in general keeping
> these names as close as possible to the actual parameter name as used
> at the command line.

Agreed. This is the best solution for these few conflicting cases.

> On the other hand, some might argue for giving all the options
> meaningful names.  The (hardly used) existing blastall wrapper in
> Bio/Blast/Applications.py gives the "-a" argument a human readable
> name of "nprocessors", and "-A" gets "window_size". With the old
> set_parameter call either alias could be used.  However, with a python
> property we need to pick one as a preferred name - and I'm not 100%
> sure being helpful and using "nprocessors" (e.g. cline.nprocessors=4)
> is actually better than using the actual argument name (e.g. cline.a =
> 4).

Could we support both the original argument and optional human
readable arguments? I know the code in Application is a bit
hard coded for the first argument as the real name and the last
argument as the readable name; the cleanest solution would be to
generalize this to have multiple names where it makes sense.

More practically, it always makes sense to have the low level
standard arguments from the program itself. Even if it is
non-intuitive like BLASTs switches, people who already understand
the program can just use their existing knowledge without any
specific knowledge of how Biopython. Where someone wants to 
support more useful names, they can add those in.

You have been digging around in this so probably have a good idea
how hard this is to implement practically. If it's a pain, I'd argue
to just have the original arguments now, and the useful names can do
on a todo list.

Brad