<div dir="auto">If people are stuck on Python 2, they do have a simple solution: use Biopython 1. That would probably be maintained at least until 2020.<div dir="auto"><br></div><div dir="auto">If Biopython 2 goes ahead (a big if) then I doubt it would be launched very soon: in the big scheme of things we are fast approaching 2020, and I doubt a first release of Biopython 2 would occur before 2018.</div><div dir="auto"><br></div><div dir="auto">With regards to the Python 3 version I would suggest supporting only the most recent when we start Biopython 3. In any case nothing before 3.5.</div><div dir="auto"><br></div><div dir="auto">In my mind the most important discussion is the module system. All the rest seems easy (lots of work still) in comparison.<br><div dir="auto"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jun 21, 2017 5:21 AM, "Peter Cock" <<a href="mailto:p.j.a.cock@googlemail.com">p.j.a.cock@googlemail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jun 20, 2017 at 10:38 PM, João Rodrigues<br>
<<a href="mailto:j.p.g.l.m.rodrigues@gmail.com">j.p.g.l.m.rodrigues@gmail.com</a><wbr>> wrote:<br>
> Iddo: +1<br>
><br>
> However, we can make it explicit that a version 2.0 is not guaranteed to be<br>
> backwards compatible.<br>
<br>
Yes - this should be very clear up front to avoid user confusion and pain.<br>
At a minimum it will mean a lot of changes to imports, but beyond that<br>
I would expect to see other changes (eg the alphabet objects are a prime<br>
target for removing/replacing).<br>
<br>
> But again, we are all volunteers and a complete<br>
> rewrite is a really big effort. I'd prefer to have a wish list kind of thing<br>
> from our users/developers and then pick a few targets that are important to<br>
> the community as things we should work on.<br>
<br>
That might be wise, although in practice we had little enough discretionary<br>
time to spend on code we're not using directly in our day jobs / research<br>
projects.<br>
<br>
> Also, dropping Py2 support isn't a good idea in my opinion. This is science,<br>
> there is a lot of code still running FORTRAN77. Python 2 is going to stick<br>
> around for years to come, specially in HPC settings.<br>
<br>
Do you object to the plan to sign up to the 2020 pledge, dropping Python 2.7<br>
support no later than 2020? <a href="http://www.python3statement.org/" rel="noreferrer" target="_blank">http://www.python3statement.<wbr>org/</a><br>
<a href="http://mailman.open-bio.org/pipermail/biopython-dev/2017-June/021739.html" rel="noreferrer" target="_blank">http://mailman.open-bio.org/<wbr>pipermail/biopython-dev/2017-<wbr>June/021739.html</a><br>
<br>
I agree that Python 2 is likely to stick around for some time, but dropping<br>
Python 2 support as part of a big backward incompatible break seems<br>
very sensible to me. We might even go further an target a particular<br>
Python 3.x version onwards if there were a compelling new language<br>
feature?<br>
<br>
> As for the rest, modularity is nice.<br>
><br>
<br>
Nice yes, but as we've seen with BioPerl interdependencies are quite<br>
painful to pick apart. On the bright side, BioRuby have done well with<br>
their modularity, and I don't see this as impossible for Biopython.<br>
<br>
> (sending again because of some mail error.. sorry if you get it twice..)<br>
<br>
Thanks,<br>
<br>
Peter<br>
<br>
______________________________<wbr>_________________<br>
Biopython-dev mailing list<br>
<a href="mailto:Biopython-dev@mailman.open-bio.org">Biopython-dev@mailman.open-<wbr>bio.org</a><br>
<a href="http://mailman.open-bio.org/mailman/listinfo/biopython-dev" rel="noreferrer" target="_blank">http://mailman.open-bio.org/<wbr>mailman/listinfo/biopython-dev</a></blockquote></div></div>