[Biopython-dev] Planning to drop Python 2 support by 2020?

[Andrew Guy]

Hi all,

Just wanted to add my thoughts as someone who is a relatively new user of
Biopython (last ~3 years) and Python in general.

I thankfully started with Python 3.x when I was first learning, and have
never needed to use Python 2.7 (that I can recall) other than to check
backwards compatibility for code I've written - the bulk of the big Python
scientific modules (e.g. Numpy, Scipy, scikit-learn) are all Python 3
compatible. To add to this, using a virtual environment (e.g. pip
virtualenv) to manage dependencies is something that everyone should be
doing, and I don't think it's asking too much to require this if anyone
wants to use an older compute cluster and a new version of Biopython.

To add to sentiments that have been expressed a few times already, I also
think it would be wonderful to be able to use some of the newer Python
features in the code base going forward, especially if there is talk of
moving to a new Biopython 2.x version.

I'll add my vote to* a)* moving to Python 3.x for Biopython 2.x and* b)*
keep a Biopython 1.x version that supports *critical* bug fixes but is
otherwise considered to be unsupported. I think the move to Biopython 2.x
would mark an excellent point from which to drop Python 2.x. Old
scripts/programs will still use the final 1.x release, whereas code that
uses the new API will be written with Python 3.x in mind.

Regards,

Andrew

On 26 June 2017 at 11:51, João Rodrigues <j.p.g.l.m.rodrigues at gmail.com>
wrote:

> As we say in Portuguese, 'this discussion grew a beard'. Tiago, you are
> absolutely right.
> ​
> I'll say it again. My opinion is that we should move to Python 3.x for
> Biopython 2.x *but* keep a version of Biopython 1.x that we support for
> critical bug fixes for those users stuck with Python 2.x (for whatever
> reason).
>
> I think we should focus on other topics such as modularity. What do the
> proponents of the said modularity say about it? What are its advantages? I
> personally think a big disadvantage is that with one package install you
> get a wide array of tools for a variety of subjects. With a constellation
> of modules you might end up with an up-to-date core and an out-of-date lone
> module somewhere, which makes things much much harder not only to maintain
> but also to debug in case of issues.
>
> (I have the impression I'm of the youngest here and already this guy
> <https://en.wikipedia.org/wiki/The_Old_Man_of_Restelo>)
>
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biopython-dev
>



-- 
*Andrew Guy*
PhD Student
*Burnet Institute*
T +613 9282 2346 <+613+9282+2346>
M +614 1987 2670 <+614+1987+2670>
E andrew.guy at burnet.edu.au
W burnet.edu.au <http://www.burnet.edu.au/>
The Macfarlane Burnet Institute for Medical Research and Public Health Ltd,
85 Commercial Road, Melbourne, VIC 3004, Australia
ABN 49 007 349 984

Equity through better health
<https://www.burnet.edu.au/system/asset/file/2392/BURNET_2020_-_web_version.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython-dev/attachments/20170626/9b66e810/attachment-0001.html>