NEP 29 - Dropping Python version support

[jacobtomlinson]

Next week numpy will be dropping Python 3.6 support as per the NEP 29 schedule.

Next week NEP 29 suggests projects start dropping support for Python 3.6.

I think Dask as a project should adopt NEP 29. What does the community think?

[gforsyth]

I'm strongly in favor of this.

[TomAugspurger]

+1

…

On Tue, Jun 16, 2020 at 11:24 AM Gil Forsyth ***@***.***> wrote: I'm strongly in favor of this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#66 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKAOIU7HWGO5GKFFLANUBLRW6MFRANCNFSM4N7YGQSQ> .

[Carreau]

Next week numpy will be dropping Python 3.6 support

Just to clarify this is not what the NEP says. It is and informational nep, and numpy/NEP is a good place to have community wide discussion and guideline. Per the NEP:

This is an unusual NEP in that it offers recommendations for community-wide policy and not for changes to NumPy itself

I actually doubt numpy will drop 3.6 in next version as it is a relatively low level dependency and they will likely be one of the last to actually remove support for 3.6 – though as a community adopting the NEP give a signal to numpy that they can drop 3.6.

Though I have been following nep29 with IPython so will drop 3.6 (at least in requirement), and I'm not going to actively make IPython incompatible with it, but I have no plan to make effort to keep it compatible.

[jakirkham]

My understanding from talking with them recently is they are dropping Python 3.5 (not 3.6) in NumPy 1.19 (due out soon). Not aware of Python 3.6 being dropped by NumPy yet. NumPy master still shows it as supported.

[rth]

I think this NEP could have been worded more neutrally. It is a proposed timeline but it's not actually being followed by core scientific python packages who co-signed it. Most dropped Python 3.5 less than a year ago, and use a slightly more conservative support window.

Also if Python 3.6 is dropped today, it would mean dropping PyPy support as well, since there is no Python 3.7 PyPy release yet. Not sure when one would happen.

[Carreau]

Most dropped Python 3.5 less than a year ago, and use a slightly more conservative support window.

Yes, roughly when the NEP was introduced and merged (in october).
So technically it's the first time that we go through a stop of support for a Python version because of this NEP.

I think this NEP could have been worded more neutrally. It is a proposed timeline but it's not actually being followed by core scientific python packages who co-signed it.

hum, well, Matplotlib, scikit-learn, IPython, Scipy only support 3.6+ (haven't checked all the rests) so I'm not sure how you can say it's not being followed. The nep say that starting with releases after next week you should consider dropping 3.6 so that leave plenty of time until next releases to stop support.

Also if Python 3.6 is dropped today, it would mean dropping PyPy support as well, since there is no Python 3.7 PyPy release yet. Not sure when one would happen.

Sure, but that does not mean people could not install old versions.

[rth]

Most dropped Python 3.5 less than a year ago, and use a slightly more conservative support window.

To be more precise numpy, scipy and jupyter notebook/lab haven't yet made a stable release (if you don't count RC) that dropped even Python 3.5 I think. More details in numpy/numpy#14086 (comment)

[MSeal]

To be more precise numpy, scipy and jupyter notebook/lab haven't yet made a stable release (if you don't count RC) that dropped even Python 3.5 I think.

Well a number of the backend libraries in Jupyter did drop python 3.5 support as they added async capabilites because it was too buggy without 3.6+ and 3.5 is nearing end-of-life. So those libraries aren't updating on jupyter notebook py3.5 deployments anymore.

[rth]

it would mean dropping PyPy support as well,

Sure, but that does not mean people could not install old versions.

Yes, but it would mean that it's not possible to run CI for PyPy on master to avoid regressions: some of the packages do that e.g. numpy, scikit-learn.

[Carreau]

Yes, but it would mean that it's not possible to run CI for PyPy on master to avoid regressions: some of the packages do that e.g. numpy, scikit-learn.

It's understandable that it's annoying, but isn't "master" of PyPy a "3.7" ? And I could see how we can workaround on CI to still install the libraries on PyPy master.

If PyPy master is not a "3.7" and libraries are not going to be compatible with 3.6, then why even test on master ? Unless I'm not following.

Regardless I'm not sure that's true, NEP 29 speaks of "support" and only suggest to setup python_requires, and that for "support"ed version one should build binary artifact. It does not define what "Not supporting" mean; that can be a gradation that goes from being actively incompatible to simply not publishing binary artifact.

Yes python_requires make it harder to install from source; it is critical when doing source release to not get random users that will start to build the sdist when pip install old python versions. But it does not make it impossible to install, nor does it tell you that the package should be incompatible.

And with this gradation there is a lot of flexibility from continuing to test on CI, with or without allow failure. or whatever author desire. – but that's IMHO a development workflow detail.

IMHO even if a project does build artifacts and set python_requires to a lower version but explicitly state in it's documentation that they are not supporting 3.6, it is in the spirit of NEP 29 and would be great.

[rth]

but isn't "master" of PyPy a "3.7" ?

I meant e.g. running numpy master with latest stable version of PyPy.

For the other suggestions I agree. A soft deprecation with delaying changing python_requires a bit would certainly make things easier.