[Biopython-dev] PEP8 lower case module names?

[Brad Chapman]

Hi all;
I don't know if there's going to be a clean way around mucking up the
API for older scripts if we make this change.

If we want to do this my thoughts would be:

- Use the 'bio' module since that's the cleanest.
- Hack together something that will remove old 'Bio' modules on install
  of the new version.
- Write a Biopython1to2 script that will fix the imports on older
  scripts to the new module structure.

However, my vote would be to stick with everything as is. I know we
aren't PEP8 compliant but things aren't that awful that we need an
upheaval. I wish Python library installs weren't so messy that we could
do this more cleanly,
Brad

> Hi guys,
>
> If I may add my two cents on this issue,  I think it's also a chance
> to rectify all other namespace issues that we may have (not just
> PEP8-related).
>
> For instance:
>
> * In the root namespace, we now have Bio.Align and Bio.AlignIO. Since
> we might be merging Bio.Seq and Bio.SeqIO into bio[py].seq (per the
> Github discussion[1]), I suppose we should do the same with Bio.Align
> as well (perhaps into bio[py].seq.align or bio[py].align).
>
> * With the change above, we might also want to change some of the
> submodule names completely. For example, if we merge Bio.Align into
> bio[py].align we'll have bio[py].align.applications, which I
> personally think could be shortened into bio[py].align.app.
>
> * As per the Github disscussion[1] as well, perhaps Bio.SeqUtils
> should also be merged as Seq object methods.
>
> There may be other changes as well, but the bottom line is all these
> changes will be quite considerable. As such, I think we could go all
> the way and be explicit in stating that the changes will be
> incompatible with previous Biopython versions (i.e. old scripts will
> break).
>
> As for bio.* and biopy.*, if we do decide to go all the way, bio.*
> seems like a better choice since there will be other incompatible
> changes anyway. But if we eventually decide to only fix PEP8-related
> issues while keeping compatibility with older versions, I'm leaning
> more towards biopy.*.
>
> regards,
> Bow
>
> [1] https://github.com/biopython/biopython/pull/63#issuecomment-8252340
>
> On Tue, Sep 4, 2012 at 12:59 PM, Peter Cock <p.j.a.cock at googlemail.com> wrote:
>> On Tue, Sep 4, 2012 at 11:27 AM, Michiel de Hoon <mjldehoon at yahoo.com> wrote:
>>> Hi Peter,
>>>
>>> --- On Tue, 9/4/12, Peter Cock <p.j.a.cock at googlemail.com> wrote:
>>>> One idea I was pondering is a new parallel namespace,
>>>> ideally bio.* but we can't use that due to case
>>>> insensitive file systems like Windows and (by default)
>>>> Mac OS X. So perhaps biopy, or bp?
>>>
>>> As you say, the ideal namespace is bio.*, so let's use
>>> that. We have been using Bio.* for more than 10 years.
>>> We should not get stuck with a non-ideal namespace for
>>> the next 10+ years because there may be some glitches
>>> switching from Bio.* to bio.*. Frankly I doubt that this
>>> will cause huge problems in practice.
>>
>> So you'd advocate a simple switch where from one
>> release to the next we change all the module names
>> (making them lower case, perhaps from consolidation
>> under bio.seq too)?
>>
>> This may cause some difficulties for upgrades - it may
>> require manual intervention to remove the old Bio folder
>> in order to allow creation of the new bio folder.
>>
>>>> We could gradually move code over to the new namespace,
>>>> using imports to preserve back compatibility - but support
>>>> both namespaces during a (long) transition period.
>>>
>>> Why do we need a transition period? It's just a matter
>>> of replacing upper case with lower case in the imports.
>>
>> That forces people to update all their scripts at once.
>> Of course, we can document how to do this so a script
>> would work before and after the case change, e.g.
>>
>> try:
>>     from bio.seq import Seq
>> except ImportError:
>>
>>     from Bio.Seq import Seq
>>
>>>> What I like about this is it allows people to make a
>>>> gradual
>>>> conversion - and we don't have to burden of two main
>>>> branches if we attempted a single jump to a Biopython v2.
>>>>
>>>> Does this seem worth considering?
>>>
>>> Yes but by all means, let's keep this simple. In the past, changes to Biopython have very rarely caused any serious problems for users.
>>>
>>> Best,
>>> -Michiel.
>>>
>> _______________________________________________
>> Biopython-dev mailing list
>> Biopython-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biopython-dev
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biopython-dev