[Biopython-dev] Proposition for Biopython 2

[Shyam Saladi]

Hi Patrick,

This looks pretty cool. I wonder two things:

1. Do you happen to have timing benchmarks comparing similar functions in
Biotite and Biopython? I'm curious about what functionality is actually
faster/sped up by numpy/cython code.

2. From a cursory look through the source and from reading your docs,
biotite seems like a significantly different module compared to the current
version of BioPython. If this sort of organization was used for a Biopython
2, it seems like it would be very difficult to port already-written,
currently developed code to the new system. That said, for those parts that
are faster, as a user, I think it might be useful to merge them into
Biopython if it's possible to do so in an API-compatible way. I wonder what
others think about this...

Thanks,
Shyam

On Wed, Nov 15, 2017 at 12:40 AM, Patrick Kunzmann <padix.kleber at gmail.com>
wrote:

> Dear Biopython community,
>
> I decided to put the proposed Biopython 2 code base into an separate
> project for the time being. The main reason for this are the clarity issues
> that have bothered me lately: Although distinguishing Biopython and the
> proposed Biopython 2 would be easy on GitHub (different repos) and
> relatively easy on PyPI (version identifier), I think confusions could
> occur in other contexts (e.g. in the mailing list or StackOverflow).
> Therefore, the project is continued unter the name 'Biotite'. The
> repository was moved into a separate GitHub organisation and can be found
> at https://github.com/biotite-dev/biotite . The project is still licensed
> under BSD 3-clause so potentially a project merge is still possible at a
> later point.
>
> Best regards,
> Patrick
>
>
> On 02.11.2017 11:42, Patrick Kunzmann wrote:
>
>> Dear Biopython community,
>>
>> here I present you a proposition for a potential Biopython 2.x code base.
>> But first things first:
>>
>> A few months ago I proposed an endeavor to rewrite Biopython in order to
>> bring it onto modern scientific Python standards (
>> http://lists.open-bio.org/pipermail/biopython-dev/2017-June/021740.html).
>> Arguably, the consensus was that this is something that should be done, but
>> those changes would require almost a complete rewrite and barely anyone has
>> time for it. Therefore, I took the initiative some time later and created
>> an experimental repository for creating actual Biopython 2 code (
>> https://github.com/padix-key/biopython2experimental). Unfortunately it
>> seems that the announcement mail for that did not reach the mailing list,
>> but went missing in the deep of the web. Anyway, the repository is now at a
>> presentable state. The corresponding HTML documentation (including
>> tutorial, API reference and install instructions) can be found under
>> https://github.com/padix-key/biopython2/files/1437242/doc.zip . So far
>> it is not possible to install the package from PyPI, since it is not the
>> offical Biopython 2 package. Instead you have to install it directly from
>> the repo, if you want to test the package.
>>
>> The package contains basic types and operations for working with
>> structure and sequence data, offers biological database interaction with
>> RCSB and NCBI Entrez and provides seamless interfaces to external software.
>> Although the package aims to achieve similar area of application as
>> Biopython 1.x, it is a complete rewrite.
>>
>> The package is still in early development. I tried to incorporate the
>> ideas you and I brought up in the Biopython 2 discussion and still
>> everything is subject to changes in the discussion with you. I already have
>> some questions for discussion:
>>
>> 1. Should this package still be dual licensed? Since the BSD 3-Clause and
>> the Biopython license are quite similar, I would suggest licensing
>> Biopython 2 only under BSD 3-Clause for clarity. But I do not have a strong
>> opinion on that.
>>
>> 2. In our previous discussion some of you proposed putting only core
>> functionality into Biopython 2 and leaving specialized code installable as
>> plugins. This package does not contain a mechanism for plugin packages,
>> yet. I would rather suggest a 'recommended packages' approach: Code that is
>> based on Biopython 2 and tackles a general biological problem would be
>> linked in a 'Recommended packages' section of the Biopython 2
>> documentation. In my opinion, direct plugins in the Biopython 2 package
>> requires some confusing namespace wizardry. Recommended packages would
>> achieve almost the same, with the slight difference, that the user writes
>> 'import recommendedpackage' rather than 'import biopython.someplugin'.
>>
>> If this package is accepted by the community, I would like to hand over
>> repository ownership to the 'Biopython' organisation on GitHub and I would
>> like to continue and supervise its development as part of the GitHub
>> 'Biopython' organisation.
>>
>> Best regards,
>> Patrick Kunzmann
>>
>>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biopython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython-dev/attachments/20171121/322aa002/attachment.html>