<div dir="ltr"><div dir="auto">Breaking back compatibility, even if explicitly stated, will probably disable some dependent software. As someone said on this thread, this is science, and there is a lot of old legacy code that, usually for budgetary reasons, cannot be maintained to accommodate breaking changes in underlying libraries.</div><div dir="auto"><br></div><div dir="auto">Caught between a rock and a hard place on this one. I don't have a good solution, I'm afraid. Just that we have to be mindful of the consequences of what we do, and understand the environment we are operating in, and who the biopython users are.</div><div dir="auto"><br></div><div>Actually, now that I think about it, maybe a user survey would help test the waters?</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 5:56 AM, Peter Cock <span dir="ltr"><<a href="mailto:p.j.a.cock@googlemail.com" target="_blank">p.j.a.cock@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, Jun 20, 2017 at 10:38 PM, João Rodrigues<br>
<<a href="mailto:j.p.g.l.m.rodrigues@gmail.com" target="_blank">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>
</span>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>
<span><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>
</span>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>
<span><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>
</span>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.or<wbr>g/</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/pi<wbr>permail/biopython-dev/2017-Jun<wbr>e/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>
<span><br>
> As for the rest, modularity is nice.<br>
><br>
<br>
</span>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>
<span><br>
> (sending again because of some mail error.. sorry if you get it twice..)<br>
<br>
</span>Thanks,<br>
<br>
Peter<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-3914940408795245709gmail_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>
</div></div>