[bip] Blog post on bioinformatics and Python

Peter biopython at maubp.freeserve.co.uk
Wed Sep 17 07:48:33 PDT 2008


Hello all,

I would have joined in with this conversation earlier but have been on holiday.

I must confess I haven't read nearly as many of Walter Scott's novels
as I would like, so didn't realise Titus was actually quoting "Old
Mortality" with his 'tweaking the proboscis' line until Andrew's
informative post.

Bruce wrote:
> Also missing is the community because I tend to concur with Andrew,
> communications must to go both ways. Part of any project is foster a
> community as it changes and for the community to foster back.  The
> latter is hard in multiple ways especially the requirement to understand
> a person's coding style that is not your own. But I definitely agree
> that starting a new project or forking one (what happened to that other
> one) should be an option of last resort.

For the record, I also agree with this stance about avoiding starting
new projects or forking old ones - which might be inferred from the
fact that I got involved with Biopython rather than starting something
from scratch.

> As previously been suggested on this list, what are the problems with
> BioPython and can these be fixed?

Specific feedback to Biopython would be very welcome - ideally on the
Biopython mailing lists, but I am subscribed here too.

> Also keep in mind that Python 3K is very near that will require
> extensive changes to any code base. So it is probably a good time to
> start addressing any issues as the developers are likely to be amenable
> to changes as the code has to change.

I was under the impression that the python team are trying to
encourage libraries NOT to use Python 3k as an excuse for API changes.
 While we can continue to gradually evolve the current Biopython API
in a backwards compatible way, discussion about bigger API changes
could help define goals for a possible "Biopython 2.0".

> Obviously there are dependencies
> on third-party modules that also have to change or these dependencies
> (e.g., Numeric) have to be removed in some way.
>
> To start this, one issue for me is the use of the unmaintained Numeric
> but numarray (a fork of Numeric) was being maintained. Consequently,
> BioPython did not fit into my code.

I am a little surprised at your view - but hearing another perspective
is instructive.  Yes, Numeric is unmaintained, but it is stable and
pretty robust.  As there is nothing to prevent having both Numeric and
numpy installed together, I personally had no problem with this when I
started to use Biopython.  Were there any other stumbling blocks for
you when you initially looked at Biopython?

> NumPy (yes, another fork of Numeric
> with some of the pieces of numarray) superseded both Numeric and
> numarray and version 1.2 is due very, very soon (that includes some of
> Andrew's fixes). Finally it would appear that BioPython will move to
> numpy although there is an mingw windows-64 bug affects the compilation
> on that platform that may delay things.

The current release, Biopython 1.48 does only support Numeric.
However, in CVS we are currently moving to supporting this and numpy.
For the pure python modules this is fairly simple, but we do have C
code to deal with too - but I'm sure additional people getting
involved and testing things would help.

> Just a few worthless cents (bailouts are welcome),

I wouldn't have said worthless (insert joke about the US dollar value here).

Peter



More information about the biology-in-python mailing list