[Biopython-dev] Code review request for phyloxml branch

[Peter]

On Mon, Jan 11, 2010 at 11:04 AM, Peter <biopython at maubp.freeserve.co.uk> wrote:
> On Sat, Jan 9, 2010 at 11:38 PM, Eric Talevich <eric.talevich at gmail.com> wrote:
>>
>> I'm trying to avoid having to update Phylo/__init__.py each time I add
>> or rename a public function in Utils.py or IO. So, how about this:
>> I've added "__all__" definitions to Utils.py and IO/__init__.py so
>> that only the relevant public functions are loaded when
>> Phylo/__init__.py imports * from those two sub-modules. Testing
>> manually, this seems to do the right thing.
>
> Previously bits of Biopython have used __all__, and then
> abandoned this a long term maintenance load. This was before
> my time, so I am not familiar with the full history, but it makes me
> wary about using __all__ here.
>
> Personally I don't see a big problem with having just explicit
> manual imports within Bio/Phylo/__init__.py if and when you
> decide a new function/class/etc in Bio/Phylo/Utils.py or IO.py
> should be made available at the top level. In general I would
> think relatively few things should be exposed like that.

In fact, why even do this at all? What is wrong with leaving
the IO functions (read, parse, write) as Bio.Phylo.IO.read etc
e.g.

>>> from Bio import Phylo
>>> tree = Phylo.IO.read(open("int_node_labels.nwk"),"newick")

What is the benefit of having them also exposed under the
Bio.Phylo namespace, e.g. as Bio.Phylo.read? This means
there are two ways to access them which is confusing.

If we do want to use Bio.Phylo.IO instead of Bio.PhyloIO
(or Bio.TreeIO) then thinking long term we may want to
do something about Bio.SeqIO and Bio.AlignIO to match.
We could move the Bio.AlignIO functionality under
Bio.Align.IO (with a suitable transition period). We could
move Bio.SeqIO to Bio.Seq.IO perhaps. Or we could
even talk about introducing Bio.Sequences (or something)
then move Bio.SeqIO to Bio.Sequences.IO, and move
Bio.SeqUtils.* under there too, and perhaps even the
Seq, SeqRecord and SeqFeature objects as well.
On the other hand, all that upheaval would cause a
lot of pain for end users, for relatively little gain.

Peter