Mailman 3 Unsupporting python3.5 - NumPy-Discussion

newer
Recommended way to utilize GPUs...

Unsupporting python3.5

older
numpy C-API :: use numpy's random...

Matti Picus

10 Oct 2019 10 Oct '19

3:31 p.m.

Attachments:

attachment.htm (text/html — 1.1 KB)

Show replies by date

Charles R Harris

10 Oct 10 Oct

4:34 p.m.

On Thu, Oct 10, 2019 at 9:31 AM Matti Picus 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

Stefan van der Walt

11 Oct 11 Oct

12:01 a.m.

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

Charles R Harris

2:17 a.m.

On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt 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

Ralf Gommers

18 Oct 18 Oct

9:05 a.m.

On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris wrote:

...

On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt 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 NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion

Charles R Harris

12:36 p.m.

On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers wrote:

...

On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:

...
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt 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

Ralf Gommers

19 Oct 19 Oct

10:41 a.m.

On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris wrote:

...

On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers wrote:

...
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:

...
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt < stefanv@berkeley.edu> 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

Charles R Harris

11:01 a.m.

On Sat, Oct 19, 2019 at 4:42 AM Ralf Gommers wrote:

...

On Fri, Oct 18, 2019 at 2:36 PM Charles R Harris < charlesr.harris@gmail.com> wrote:

...
On Fri, Oct 18, 2019 at 3:06 AM Ralf Gommers wrote:

...
On Fri, Oct 11, 2019 at 4:18 AM Charles R Harris < charlesr.harris@gmail.com> wrote:

...
On Thu, Oct 10, 2019 at 6:02 PM Stefan van der Walt < stefanv@berkeley.edu> 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

Evgeni Burovski

11:40 a.m.

...

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

...

1649

Age (days ago)

1658

Last active (days ago)

List overview

Download

8 comments

5 participants

participants (5)

Charles R Harris
Evgeni Burovski
Matti Picus
Ralf Gommers
Stefan van der Walt

Unsupporting python3.5

tags

participants (5)