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

[Peter Cock]

Dear fellow Biopythoneers,

Or next release (Biopython 1.69) drops Python 2.6 support, and will
target Python 2.7 and Python 3.3 onwards.

While Python 2.7 support will continue in the short to medium term,
the Python team themselves currently plan to stop support by 2020.
That is only three or four more years, and seems a sensible upper
limit for how long Biopython continues to support Python 2.7.

Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/

Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?

Thanks,

Peter

[Peter Cock]

Hello all,

I raised the idea of planning to drop Python 2 support by 2020
here on the developers list last year with no reply, and on tTwitter
where there were some positive replies.

Biopython 1.69 is now out, and with it we have formally dropped
support for Python 2.6, but we still support Python 2.7 for now.

If no one objects, then next week I will write to the main mailing
list, and our announcement list, stating this is our intension.

Then if there are no reasoned objections, we can add this to
the website and README.rst etc, and ask to be added to
http://www.python3statement.org/

Thanks,

Peter

Post by Peter Cock
Dear fellow Biopythoneers,
Or next release (Biopython 1.69) drops Python 2.6 support, and will
target Python 2.7 and Python 3.3 onwards.
While Python 2.7 support will continue in the short to medium term,
the Python team themselves currently plan to stop support by 2020.
That is only three or four more years, and seems a sensible upper
limit for how long Biopython continues to support Python 2.7.
Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/
Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?
Thanks,
Peter

[Peter Cock]

Dear Biopythoneers,

With the recent release of Biopython 1.69 we have dropped
support for Python 2.6, and target Python 2.7 and Python 3.3
onwards.

The Python team will continue to support Python 2.7 in the
medium term, but currently plan to stop support in 2020.
This seems a sensible upper limit for how long Biopython
continues to support Python 2.7.

Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/

Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?

Please reply to the mail discussion list and/or the developers
list (the announcement mailing list will not accept any replies).

(I've raised this on the Biopython developers mailing list before
Christmas and last with no objections)

Thank you,

Peter

[João Rodrigues]

Hi Peter,

All good for me. Thanks for raising this again!

João

Post by Peter Cock
Dear Biopythoneers,
With the recent release of Biopython 1.69 we have dropped
support for Python 2.6, and target Python 2.7 and Python 3.3
onwards.
The Python team will continue to support Python 2.7 in the
medium term, but currently plan to stop support in 2020.
This seems a sensible upper limit for how long Biopython
continues to support Python 2.7.
Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/
Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?
Please reply to the mail discussion list and/or the developers
list (the announcement mailing list will not accept any replies).
(I've raised this on the Biopython developers mailing list before
Christmas and last with no objections)
Thank you,
Peter
_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

[Christian Brueffer]

+1, seems a good timeline especially considering precedence by related
projects.

Chris

Post by João Rodrigues
Hi Peter,
All good for me. Thanks for raising this again!
João
Dear Biopythoneers,
With the recent release of Biopython 1.69 we have dropped
support for Python 2.6, and target Python 2.7 and Python 3.3
onwards.
The Python team will continue to support Python 2.7 in the
medium term, but currently plan to stop support in 2020.
This seems a sensible upper limit for how long Biopython
continues to support Python 2.7.
Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/
<http://www.python3statement.org/>
Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/
<http://www.python3statement.org/> ?
Please reply to the mail discussion list and/or the developers
list (the announcement mailing list will not accept any replies).
(I've raised this on the Biopython developers mailing list before
Christmas and last with no objections)
Thank you,
Peter
_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev
<http://mailman.open-bio.org/mailman/listinfo/biopython-dev>
_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

[Peter Cock]

Correction: NumPy itself is not yet listed on
http://www.python3statement.org/ but a number
of related projects like SciPy are. My mistake, sorry.

NumPy are discussing when to drop Python 2.7
support on their mailing list right now:

https://mail.python.org/pipermail/numpy-discussion/2017-April/076653.html

I don't think this fundamentally changes the fact we
should be planning for the end of life for Python 2.7,
and that 2020 is a sensible target.

Regards,

Peter

Post by Peter Cock
Dear fellow Biopythoneers,
Or next release (Biopython 1.69) drops Python 2.6 support, and will
target Python 2.7 and Python 3.3 onwards.
While Python 2.7 support will continue in the short to medium term,
the Python team themselves currently plan to stop support by 2020.
That is only three or four more years, and seems a sensible upper
limit for how long Biopython continues to support Python 2.7.
Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/
Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?
Thanks,
Peter

[Peter Cock]

My fellow Biopythoneers,

I've only seen positive replies, so I propose to add this
commitment to the README.rst file, FAQ in the Tutorial,
and NEWS.rst entry for upcoming biopython 1.70 release.

Let's say at the start of next week if no one objects?

We can then ask to have Biopython added to the
http://www.python3statement.org/ site (using the new
logo - yay!).

We can also include this in the Biopython Project Update
2017 talk at BOSC next month.

Regards,

Peter

Post by Peter Cock
Correction: NumPy itself is not yet listed on
http://www.python3statement.org/ but a number
of related projects like SciPy are. My mistake, sorry.
NumPy are discussing when to drop Python 2.7
https://mail.python.org/pipermail/numpy-discussion/2017-April/076653.html
I don't think this fundamentally changes the fact we
should be planning for the end of life for Python 2.7,
and that 2020 is a sensible target.
Regards,
Peter

Post by Peter Cock
Dear fellow Biopythoneers,
Or next release (Biopython 1.69) drops Python 2.6 support, and will
target Python 2.7 and Python 3.3 onwards.
While Python 2.7 support will continue in the short to medium term,
the Python team themselves currently plan to stop support by 2020.
That is only three or four more years, and seems a sensible upper
limit for how long Biopython continues to support Python 2.7.
Furthermore, NumPy (which a lot of our code depends on) and
other high profile relevant projects also intend to drop their
Python 2.7 support by 2020 as advertised on this campaign
site: http://www.python3statement.org/
Does anyone object to adopting this goal for Biopython, and
adding the project to http://www.python3statement.org/ ?
Thanks,
Peter

[João Rodrigues]

Hi Peter (and all),

Don't take me wrong. I do agree that it is a good idea, I just think it's
very hard to implement in practice. As I mentioned in the other thread, I
work with code written in the 80s, that's how it is in some fields. I only
recently moved to Python 3.x because I got a new laptop and decided to take
the plunge... all my code works with Python 2 and I rarely make use of 3.x
features (maybe I should?). I had to do some fixing to some of my scripts
but that's because I wrote them and I am fairly familiar with the language.
A user of a script or of a library would very likely not know how to fix
it, and we all know how often zombie code survives after the original
developer moved on to another lab/position. Regardless, as Tiago mentioned,
many other Python libraries will drop support anyway so we'll be left
behind. He's right.

My only recommendation would be to have a release that supports Python 2.x
and keep that available for download. Perhaps even still support it
regarding bug fixing, but freeze any new features. This way we can still
support any users left with Python 2.x on their systems, whether because
upgrading causes a bunch of problems or because they are actually
technically incapable of doing it themselves, or both.

Cheers,

João

[Peter Cock]

Thanks for the clarification Joao,

I have only started using Python 3 as my main version of Python
this year - and am aware that the need to continue to support
Python 2.7 in Biopython has constrained me from adopting some
of the new features in Python 3.x.

Even if we do eventually drop Python 2 support in 2020, we would
not actively remove or prevent people using the older releases of
Biopython. We can explicitly list the final Python 2 compatible
release on our download page too, as I would not be surprised to
have a fraction of people continuing to use Python 2 beyond 2020.

While I would want to make any commitment to do so at this point,
I would likely be sympathetic to creating a branch should there be
a strong case for an extra point release to address an important bug.
I think that would be consistent with the spirit and wording of the
pledge on http://www.python3statement.org/

So, do you agree with Biopython signing up to that pledge?

Regards,

Peter

On Thu, Jun 22, 2017 at 11:19 AM, João Rodrigues

Post by João Rodrigues
Hi Peter (and all),
Don't take me wrong. I do agree that it is a good idea, I just think it's
very hard to implement in practice. As I mentioned in the other thread, I
work with code written in the 80s, that's how it is in some fields. I only
recently moved to Python 3.x because I got a new laptop and decided to take
the plunge... all my code works with Python 2 and I rarely make use of 3.x
features (maybe I should?). I had to do some fixing to some of my scripts
but that's because I wrote them and I am fairly familiar with the language.
A user of a script or of a library would very likely not know how to fix it,
and we all know how often zombie code survives after the original developer
moved on to another lab/position. Regardless, as Tiago mentioned, many other
Python libraries will drop support anyway so we'll be left behind. He's
right.
My only recommendation would be to have a release that supports Python 2.x
and keep that available for download. Perhaps even still support it
regarding bug fixing, but freeze any new features. This way we can still
support any users left with Python 2.x on their systems, whether because
upgrading causes a bunch of problems or because they are actually
technically incapable of doing it themselves, or both.
Cheers,
João

[João Rodrigues]

Hi Peter,

I believe we are on the same page, I just think it's important to mention
these issues explicitly in writing somewhere because they *will* pop up.
The pledge should highlight that it drops support for *developing* for
Python 2.x, and this I completely agree with. However, I am firmly against
dropping *all* support for users stuck with Python 2.x. It's a matter of
wording and interpretation of the pledge text I guess..

So yes, I agree.

Cheers,

João

[Peter Cock]

Thank Joao,

I am interpreting the pledge as dropping any expectation of support
for Biopython on Python 2 after 2020, but with enough leeway for an
emergency fix release if required after thereafter.

(Much like how Microsoft officially ended Windows XP support some
time ago, but does occasionally release critical security fixes)

Peter

On Thu, Jun 22, 2017 at 11:49 AM, João Rodrigues

Post by João Rodrigues
Hi Peter,
I believe we are on the same page, I just think it's important to mention
these issues explicitly in writing somewhere because they *will* pop up. The
pledge should highlight that it drops support for developing for Python 2.x,
and this I completely agree with. However, I am firmly against dropping all
support for users stuck with Python 2.x. It's a matter of wording and
interpretation of the pledge text I guess..
So yes, I agree.
Cheers,
João

[Tiago Antão]

Hi,

I understand that some folks (surely not only Joao) have old code, but to
be quite frank, supporting old code is shifting the burden to us by
something we have no real fault. It is not our responsibility if people did
not take appropriate decisions over time. Should we be supporting Python 1?

Other than a burden on us, it is also a burden on users that did the
recommended thing (remember this comes from CPython - not us) because
Biopython could be using more modern features and it is not.

Also, being quite cynical, I think the project would profit more to be
modern than supporting very old stuff. Biopython shows its age. Compared to
any other big Python project out there that I can think off. it is clearly
behind the curve.

Come 2020, old Biopython versions will always be available, people should
use those if they need Python 2 support.

Post by Peter Cock
Thank Joao,
I am interpreting the pledge as dropping any expectation of support
for Biopython on Python 2 after 2020, but with enough leeway for an
emergency fix release if required after thereafter.
(Much like how Microsoft officially ended Windows XP support some
time ago, but does occasionally release critical security fixes)
Peter
On Thu, Jun 22, 2017 at 11:49 AM, João Rodrigues

Post by João Rodrigues
Hi Peter,
I believe we are on the same page, I just think it's important to mention
these issues explicitly in writing somewhere because they *will* pop up.

The

Post by João Rodrigues
pledge should highlight that it drops support for developing for Python

2.x,

Post by João Rodrigues
and this I completely agree with. However, I am firmly against dropping

all

Post by João Rodrigues
support for users stuck with Python 2.x. It's a matter of wording and
interpretation of the pledge text I guess..
So yes, I agree.
Cheers,
João

_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

[João Rodrigues]

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>)

[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

Post by João Rodrigues
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
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

--
*Andrew Guy*
PhD Student
*Burnet Institute*
T [phone] <+613+9282+2346>
M [phone] <+614+1987+2670>
E ***@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>

[Peter Cock]

Thanks Andrew,

I think we are agreed about dropping Python 2.7 support by 2020, although
please do comment on the Biopython 2 thread as well.

I will prepare a pull request adding the 2020 language to the README.rst
and NEWS.rst files, and once that's merged we can ask to be added to
http://www.python3statement.org/

Peter

Post by 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

Post by João Rodrigues
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
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

--
*Andrew Guy*
PhD Student
*Burnet Institute*
T [phone] <+613+9282+2346>
M [phone] <+614+1987+2670>
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>
_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

[Peter Cock]

I'm in Prague for the pre-BOSC 2017 CodeFest, where quite a few
Biopython contributors are present, and finally wrote this pull request:

https://github.com/biopython/biopython/pull/1333

Peter

Post by Peter Cock
Thanks Andrew,
I think we are agreed about dropping Python 2.7 support by 2020, although
please do comment on the Biopython 2 thread as well.
I will prepare a pull request adding the 2020 language to the README.rst
and NEWS.rst files, and once that's merged we can ask to be added to
http://www.python3statement.org/
Peter

Post by 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

Post by João Rodrigues
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
http://mailman.open-bio.org/mailman/listinfo/biopython-dev

--
*Andrew Guy*
PhD Student
*Burnet Institute*
T [phone] <+613+9282+2346>
M [phone] <+614+1987+2670>
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>
_______________________________________________
Biopython-dev mailing list
http://mailman.open-bio.org/mailman/listinfo/biopython-dev