Unsupporting python3.5

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Unsupporting python3.5

mattip
Administrator

According to NEP 29, numpy 1.18 will be released after Sept 2019, which as I understand it is the cutoff for Python 3.5. In PR 14673 I proposed removing it from the test matrix and also removing some shims in the code to support it - meaning that in order to use Numpy 1.18+ you will need to use Python 3.5+. Is this the intention of the NEP or is the intention only that we no longer test it and no longer supply wheels? If the latter, at what point do we remove support code for unsupported versions?


Note the cost of this code is negligible, it is more a question of what is the correct/desired approach.


Matti


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Charles R Harris


On Thu, Oct 10, 2019 at 9:31 AM Matti Picus <[hidden email]> wrote:

According to NEP 29, numpy 1.18 will be released after Sept 2019, which as I understand it is the cutoff for Python 3.5. In PR 14673 I proposed removing it from the test matrix and also removing some shims in the code to support it - meaning that in order to use Numpy 1.18+ you will need to use Python 3.5+. Is this the intention of the NEP or is the intention only that we no longer test it and no longer supply wheels? If the latter, at what point do we remove support code for unsupported versions?


Note the cost of this code is negligible, it is more a question of what is the correct/desired approach.


I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Stefan van der Walt
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

The language in the NEP is:

"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"

i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged.  The NEP is meant to lift the burden of very long support cycles from smaller projects.

Stéfan




_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Charles R Harris


On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <[hidden email]> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

The language in the NEP is:

"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"

i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged.  The NEP is meant to lift the burden of very long support cycles from smaller projects.

Stéfan


The 1.18.0rc1 is about one month out, so we should spend some effort on those PRs and issues with the 1.18 milestone. Dealing with issues and milestones, plus putting together the release notes, is the major pain point in making releases these days.

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

ralfgommers


On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris <[hidden email]> wrote:


On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <[hidden email]> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.

Cheers,
Ralf

The language in the NEP is:

"we recommend that they support at least all minor versions of Python introduced and released in the prior 42 months"

i.e., a lower bound for support, such that compatibility with more versions of Python is perfectly OK and, in the case of NumPy, probably encouraged.  The NEP is meant to lift the burden of very long support cycles from smaller projects.

Stéfan


The 1.18.0rc1 is about one month out, so we should spend some effort on those PRs and issues with the 1.18 milestone. Dealing with issues and milestones, plus putting together the release notes, is the major pain point in making releases these days.

Chuck
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Charles R Harris


On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers <[hidden email]> wrote:


On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris <[hidden email]> wrote:


On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <[hidden email]> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.


That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

ralfgommers


On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris <[hidden email]> wrote:


On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers <[hidden email]> wrote:


On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris <[hidden email]> wrote:


On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <[hidden email]> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.


That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.

So do you have a preference for dropping or not dropping for 1.18?

Ralf


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Charles R Harris


On Sat, Oct 19, 2019 at 4:42 AM Ralf Gommers <[hidden email]> wrote:


On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris <[hidden email]> wrote:


On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers <[hidden email]> wrote:


On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris <[hidden email]> wrote:


On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt <[hidden email]> wrote:
On Thu, Oct 10, 2019, at 09:34, Charles R Harris wrote:
I think we can support 3.5 as long as we please, the question is how long we *want* to support it. I don't plan to release 1.18 wheels for 3.5, but I'm concerned about making 1.18 outright incompatible with 3.5. I would like to see the random interface settle before we do that. So my preference would be to drop 3.5 in 1.19 with a future warning in the 1.18 release notes. Alternatively, we could backport all the random changes to 1.17, but I would rather not do that. 

I'm not sure I like this approach, which is reflected in the current version of https://github.com/numpy/numpy/pull/14673. If we stop testing 3.5 in CI, don't release 3.5 wheels and remove the PyPI trove classifier for it (so installation tools may not install it anymore), then what's the point of saying we "don't drop it"? I'd rather keep it fully supported for one more month and release a couple of wheels, or just drop it completely. I don't have much of a preference which option is better, just would like to avoid half-dropping it.


That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.

So do you have a preference for dropping or not dropping for 1.18?

Let's not drop it. Four weeks isn't that long to wait.

Chuck 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Unsupporting python3.5

Evgeni Burovski


That's fair. The 1.17.3 release supporting Python 3.5--3.8 went well enough. The only glitch was that I had to explicitly use OSX 10.6 and icode 6.4 for the 3.5 wheels on the Mac.

So do you have a preference for dropping or not dropping for 1.18?

Let's not drop it. Four weeks isn't that long to wait.

+1 from the peanut gallery.

Cheers,

Evgeni



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion