[Biopython-dev] Code review request for phyloxml branch

[Peter]

On Mon, Jan 11, 2010 at 3:02 PM, Michiel de Hoon wrote:
>
> On Mon, 1/11/10, Peter wrote:
>> 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 use Bio.Phylo.IO.read directly, then for consistency we'd have
> to do the same for all other modules. Otherwise, we'd be guessing
> each time whether the read() and parse() functions are in
> Bio.SomeModule, or Bio.SomeModule.IO.

Fair point.

> For Bio.Phylo, a simple solution is to put whatever is in
> Bio.Phylo.IO.__init__.py in Bio.Phylo.__init__.py, and
> remove Bio.Phylo.IO.__init__.py. Then there is only one
> way to access the read() etc. functions.

Or (if the functions are reasonably complex) keep the
input/output code in a separate file, but make it explicit
that it is not a public interface - e.g. use Bio/Phylo/_IO.py?

> [About doing the same for Bio.Seq and Bio.Align]
>> On the other hand, all that upheaval would cause a
>> lot of pain for end users, for relatively little gain.
>
> For new users, it may be confusing to have all those
> different modules dealing with sequences. At least, it
> was for me when I started with Biopython. Therefore,
> for a long term solution, I'd prefer a single Bio.Seq
> module that incorporates all (Seq, SeqRecord, SeqIO,
> SeqFeature).

I agree that for a long term solution a single module
make sense here, although I'm not convinced that
Bio.Seq is the best name. We'd have to switch from
a single file Bio/Seq.py to a folder with multiple files
including Bio/Seq/__init__.py - I worry this may cause
problems with updating existing Biopython installations.

> I agree that that may cause a lot of upheaval for end
> users, but a suitably long transition period may mitigate
> those concerns. I'd prefer that to being stuck with a
> less-than-optimal code organization forever.

In principle I agree with that.

Peter