[BioPython] Questions & suggestions

Jeffrey Chang jeffrey_chang at stanfordalumni.org
Sun Mar 21 16:30:09 EST 2004


On Mar 21, 2004, at 12:46 PM, Brad Chapman wrote:

> Yes, I've not been a fan of HappyDoc for a while. I was pointed to,
> and really like, epydoc. Please take a look at:
>
> http://biopython.org/docs/api/private/trees.html

This looks very nice to me.  Is there any way to ask it to hide private 
methods or variables, i.e. those that begin with "_"?  Although knowing 
what those are is occasionally useful, exposing that extra information 
may be confusing for people reading the docs and trying to figure out 
how to use the module.


>> 2) Online comments from users, like in the Zope or MySQL manuals. that
>> would be helpful in identifying glaring gaps in the docs.
>
> This is a good idea, but also along the lines of my biases against
> trying to be fancier than we need to be. Honestly, the user bases of
> Zope or MySQL dwarf those of Biopython (although we are catching up
> fast :-) and I don't want to put the cart before the horse (or
> however that cliche goes).

Agreed.  People did not take to our wiki, and bioperl doesn't use 
theirs much either.



> [Removal/Deprecation of modules]
> Thomas:
>> We could make a list of modules that will be potentially removed, 
>> post it to
>> the biopython list, and then actually remove them when no-one 
>> objects. Is
>> anybody using the two HMMs (HMM and MarkovModel) for instance? Or the
>> support vector machine (SVM) and NeuralNetwork modules?
>
> Is potential non-use (or trying to assess non-use) really a good
> model to remove modules? If they work and are decently coded then I
> think they have a potential use -- I definitely do know that a lot of 
> the
> different supervised learning methods are useful to people doing
> clustering of literature (which is what I'm pretty positive Jeff
> worked on for his thesis).
>
> If things don't work, or are duplicated, then I'm in favor of trying
> to get rid of that, but working code seems useful to me.
>
> Thomas:
>> The xKMeans,
>> KNN and KMeans clustering modules also seem to be obsolete in view of 
>> Michiel
>> de Hoons clustering module.
>
> Michiel:
>> The xKMeans and KMeans can be considered obsolete, as they are 
>> included in
>> Bio.Cluster. The KNN and other modules under Bio/Tools/Classification 
>> are
>> currently not obsolete, as they contain supervised learning methods, 
>> which
>> are not included in Bio.Cluster.
>
> If things are duplicated then the right thing to do is to remove the
> duplication. I'd like to consider two things, though:
>
> 1. I'd like Jeff to chime in since these are his modules (I think).
> I don't have enough knowledge about clustering to know if
> Bio.Cluster also does the things that he needed his code to do.

kMeans is superceded by Bio.Cluster, and can be deprecated.  Thomas 
wrote xkMeans, which is a visualizer for kMeans, and could be rewritten 
to use Bio.Cluster instead.

MarkovModel is redundant with HMM.  Probably only one of them is 
necessary.

SVM is superceded by libsvm.  It should be deprecated.

kNN, LogisticRegression, MaxEntropy, and NaiveBayes are still useful, 
but need more documentation.  Also, another idea is that they could be 
donated to the pyml project.  Currently, no code in Biopython depends 
on them.  However, they might be useful for a microarray package, in 
which case donating them would introduce another dependency.

Jeff



More information about the BioPython mailing list