<div dir="ltr">One of the reasons I believe this is going nowhere is because of the amount of work needed (not our day job).<div><br></div><div>But I do not understand the rest of your comments: Biopython 2 would break back-compatibility by definition, right? That is acceptable. Of course if we can maintain some APIs that would be an added bonus (or even share code).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 June 2017 at 09:48, Iddo Friedberg <span dir="ltr"><<a href="mailto:idoerg@gmail.com" target="_blank">idoerg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:12.8px">> On the big picture, I wholeheartedly agree that Bioptyhon 2.0 should adopt modern Python best practices, even if it requires a close to full rewrite. </span></span><div><span style="font-size:12.8px"><br></span><div><span style="font-size:12.8px">I would be very careful with putting efforts into a deliberate code rewrite for the sake of it, as (1) bp is not really anyone's day job  and (2) a major danger in rewrites is that they may break back-compatibility, either with code (beyond the 3.x fork move which is inevitable), or, more insidiously, through modified output. Note that bp is a component in a large number of operation bioinformatics software out there, and we have a responsibility to the people using it. </span></div></div><div><span style="font-size:12.8px"><br></span></div><div><br></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Jun 20, 2017 at 2:58 AM, Wibowo Arindrarto <span dir="ltr"><<a href="mailto:w.arindrarto@gmail.com" target="_blank">w.arindrarto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Dear Patrick, Peter, Tiago, and everyone,</div><div><br></div><div>Good to see this discussion being brought up again :) (and thank you Patrick for writing a thorough proposal).</div><div><br></div><div>On the big picture, I wholeheartedly agree that Bioptyhon 2.0 should adopt modern Python best practices, even if it requires a close to full rewrite. The Python scientific computing environment has progressed far beyond the time when Biopython was first written. Many scientific Python libraries are now mature and widely used that at least the thought of interop with them should be considered. This can be done, for example, making our data structures compatible with them (e.g. using numpy arrays) or by making our plotting functions (in Bio.Graphics, for example) compatible with them (e.g. using matplotlib or bokeh).</div><div><br></div><div>I don't have any strong preference for the new namespace (biopy.* or biopython.* is fine). But depending on how we structure the new modules, we may or may not need to share the namespace with the current Bio package, right? If we opt to do modularization ala biogems, only the core module is probably suitable for inclusion in the current Bio package. The rest would have their own repositories.</div><div><br></div><div>I did play around with a distributed package setup (<a href="https://github.com/bow/poc_biopy" target="_blank">https://github.com/bow/poc_bi<wbr>opy</a>). There are two alternatives that I considered there. The first one, `poc_hook` uses an import hook so any non-core `biopy_*` package can be imported as `biopy.ext.*`. The second, `poc_pkgutil` one simply requires any non-core `biopy_*` package put their code inside `biopy.ext`. This was from about 3 years ago, however, so there may be better ways of doing this now.</div><div><br></div><div>But as Peter said, this is probably the one on which a consensus is hardest to build. In addition to that, we would need work to port existing packages to the new structure.</div><div><br></div><div>Now seems like a good time to attempt to do this, though :).</div><div><br></div><div>Cheers,</div><div>Bow</div></div><div class="m_-6345322129092876672HOEnZb"><div class="m_-6345322129092876672h5"><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 19, 2017 at 10:43 PM Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yep - that's what I meant :)<br>
<br>
i.e. "biopython" (or "biopy" or ...") as a folder name meaning we'd<br>
have for example "biopython/sequences/__init__.<wbr>py`` which can<br>
be import as "from biopython import sequences" etc.<br>
<br>
The NumPy/SciPy like usage pattern for importing had crossed my<br>
mind too - although if we try to minimise the top level automatic<br>
imports I think that is less useful?<br>
<br>
(By that I mean that for example people doing clustering would not<br>
want the overhead of lots of sequence code being imported by default)<br>
<br>
Peter<br>
<br>
On Mon, Jun 19, 2017 at 3:47 PM, Tiago Antão <<a href="mailto:tiagoantao@gmail.com" target="_blank">tiagoantao@gmail.com</a>> wrote:<br>
> Or even<br>
> biopython.*<br>
> and have a recommendation of<br>
> import biopython as bp<br>
> Tiago<br>
><br>
> On 19 June 2017 at 08:45, Peter Cock <<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>> wrote:<br>
>><br>
>> I am generally in agreement with your comments Tiago.<br>
>><br>
>> Note as per my reply to Patrick, we can't use "bio" (lower case)<br>
>> as this would be the same directory on disk as "Bio" (title case) on<br>
>> Windows and most Macs which use a case-insensitive file system.<br>
>> Thus suggestions like "biopy" and "biopython" instead.<br>
>><br>
>> Peter<br>
>><br>
<br>
______________________________<wbr>_________________<br>
Biopython-dev mailing list<br>
<a href="mailto:Biopython-dev@mailman.open-bio.org" target="_blank">Biopython-dev@mailman.open-bio<wbr>.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biopython-dev" rel="noreferrer" target="_blank">http://mailman.open-bio.org/ma<wbr>ilman/listinfo/biopython-dev</a></blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
Biopython-dev mailing list<br>
<a href="mailto:Biopython-dev@mailman.open-bio.org" target="_blank">Biopython-dev@mailman.open-bio<wbr>.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biopython-dev" rel="noreferrer" target="_blank">http://mailman.open-bio.org/ma<wbr>ilman/listinfo/biopython-dev</a><br></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-6345322129092876672gmail_signature" data-smartmail="gmail_signature">Iddo Friedberg<br><a href="http://iddo-friedberg.net/contact.html" target="_blank">http://iddo-friedberg.net/<wbr>contact.html</a><br>++++++++++[>+++>++++++>+++++++<wbr>+>++++++++++>+++++++++++<<<<<-<wbr>]>>>>++++.><br>++++++..----.<<<<+++++++++++++<wbr>+++++++++++++++.-----------..><wbr>>>+.-----.<br>.>-.<<<<--.>>>++.>+++.<+++.---<wbr>-.-.<++++++++++++++++++.>+.>.<<wbr>++.<<<+.>><br>>>----.<--.>++++++.<<<<-------<wbr>-----------------------------.<br></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Tiago Antao<div>Scientific and HPC programmer</div><div><a href="http://tiago.org" target="_blank">http://tiago.org</a></div><div><a href="https://github.com/tiagoantao/" target="_blank">https://github.com/tiagoantao/</a><br></div></div></div>
</div>