[Biopython-dev] PEP8 lower case module names?

[Eric Talevich]

On Tue, Oct 30, 2012 at 7:03 AM, Peter Cock <p.j.a.cock at googlemail.com>wrote:

> On Mon, Oct 29, 2012 at 5:54 PM, Brad Chapman <chapmanb at 50mail.com> wrote:
> >
> > Peter;
> >
> >> In the case of Bow's SearchIO code, what would you prefer?
> >> e.g. Bio.SearchIO as it is now on his branch?
> >
> > I like plain ol' Search the best but don't have a strong preference. I'm
> > terrible at naming things so trust everyone's judgment on this.
> >
> > Brad
>
> Since we have no clear consensus, I propose we add Bow's code
> as Bio.SearchIO (which is how it is written right now), with the new
> BiopythonExperimentalWarning in place (to alert people that it may
> change in the next release). We can then rename or move it at a
> later date. This will make it easier for people to test the code, and
> also suggest further changes or additions (e.g. Kai's HMMER work).
>
> If we and when we agree a consolidation of the Bio.SeqXXX
> modules, then Bio.SearchIO could move too. If this happens
> before any public release as Bio.SearchIO so much the better.
>
> Adopting lower case module names under Python 3 is also a
> separate issue.
>
> Peter
>
>
+1

Regarding the "great upheaval" of module renaming and reorganization:

0. If the only change is to combine the SeqIO, Seq, SeqRecord and
SeqFeature classes under a single module, we probably can do that in a
backwards-compatible way. But that means keeping our StudlyCaps module
names for the most part.

1. If we're going to change the API substantially, we might as well "do it
right". Besides our PEP8 non-compliance, there are some dark, dusty corners
of Biopython that we ought to clean up while we're at it -- reorganize the
little historical fiefdoms into a coherent structure. We'd call it
Biopython 2.

2. Observing BioPerl and BioRuby, it could make sense to split the
distribution into multiple, with a sequence- and data-oriented
"biopython-core" package and separate packages for, say, 3D structures
("biopython-struct") and perhaps other existing components that have ready
maintainers and which the "core" of Biopython doesn't rely on. I don't
think we need to fragment the code base much, primarily just extract PDB,
SCOP and the other parts that depend on NumPy. On GitHub, these
repositories would still be under the biopython organization name.

3. If we've decided to focus on Python 3 for the reorganization, we can
take advantage of new features in that lineage for packaging, organization
and distribution. These features could make it easier to have side-by-side
Biopython 1 and 2 installations (maybe), and also plugging additional
modules into the main "bio" package (namespace packages, new in Py3.3).

4. Naming: "bio" is clean but might cause problems on Windows? (I wouldn't
know, nyah); "bio2" is nearly as clean; "biopy" follows the numpy/scipy
convention.

5. Porting: I, personally, would keep using the old Biopython for
everything that's meant to run on Python 2, which is, currently,
everything. Biopython2 running on Python 3 would give me an excuse to start
using Python 3 for new code. Keeping these separate would be more difficult
if the lowercasing were done under the same "Bio" namespace.

Thoughts?

-Eric