[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
Hi, Is there any way to know if other large libraries hasn't set an upper pin in their last release but since then dropped python version support? Brigitta On Fri, 10 May 2024 at 07:47, Ralf Gommers wrote: > > > On Thu, May 9, 2024 at 12:28 AM Thomas Caswell wrote: > >> I think the spirit of NEP 29 is to pick your supported Python's when you >> pick a target release date and you should then stick to it (to avoid "we >> delayed so long we are over a cliff" decisions like this one). >> > > That's true I believe. > > >> We did NEP29 around the same time that Python went from 18 to 12 month >> releases (my memory is that the cadence change was being considered but not >> set). If Python is targeting an 18mo release cycle, then a 36mo window + >> 2mo delayed Python release could land you in only supporting one version of >> Python which seems too few (again, my memory could be a bit off). I was >> not at the meeting where SPEC 0 was discussed, >> > > Same here, I wasn't at that meeting so am unsure. I only got added to SPEC > 0 as a co-author at the end because it's mostly a copy of NEP 29. "change > in release cycle" is probably right as the motivation though. > > >> but I suspect that the narrowing is to better align with an integer >> number of Python releases while always hitting at least 2 versions of >> Python. >> > > At least 3, right? 36 months is always 3 minor versions. > > > >> >> >> It is worth considering that CPython has both a concept of "bugfix" >> (which is 18mo) and "security" (which is 42mo and source-only) support. It >> is arguable that by having "new feature" support and binary release >> targeting a given version of Python for 36mo we are supporting a given >> minor version of Python longer than upstream [speaking for myself I would >> sign onto a proposal to do security release against the last version of our >> libraries for all versions of Python that still have security support]. >> >> >> >> > So only 30% of users have Python 3.10+ or newer. Most smaller or newer >> projects can more than double their user base by supporting 3.8+. I could >> even argue that 3.7+ is still helpful for a new project. Once a library is >> large and stable, then it can go higher, even 3.13+ and not hurt anyone >> unless there's a major development. >> >> I have the exact opposite view of Henry here, I think for new projects >> you should be very aggressive and only support the newest Python version as >> you don't have any users (so do not have to be responsible yet)! >> > > I think what you do as a new project author totally depends on your goals > and priorities. Either way, the argument that only so few users "have a new > Python" seems a bit off-target. That's not how people think - they look for > new packages to use when they need functionality, and once they find > something that fits their needs, they make it work. Nor are the statistics > reflective of usage needs, especially for manylinux - it's more that > production deployments stay on the same version of Python for their own > lifetime I suspect. But such deployments also pin all their dependencies, > so they're irrelevant to new versions/projects. > > It gets ever-easier to install new Python versions, with pyenv/conda/etc. > The "my single Python install comes from python.org and I'm using the > same one because I am afraid to upgrade" is much less of an issue than it > was 10 years ago. And it's caused mostly by users having knowledge gaps. So > yes it can be a pain for them, but they'll have to learn at some point > anyway. Same for "my old HPC cluster uses ..." - it's often an even older > Python anyway, and you'll have tons of reasons why you don't want your > cluster-installed stack - learn to use Spack or Conda, and you'll be much > happier in the long run. > > --- > > Back to the topic of dropping 3.9 here: there seem to be some minor > concerns. Tom is right about the spirit of NEP29/SPEC0. And Sebastian is > partially right I think: not about `pip install scipy-image==0.22`, because > that should be picking 0.22.1 plus an older numpy; but `==0.22.0` instead > cannot be fixed anyway, and that's perhaps a more common way of spelling an > `==` constraint. So the last-minute dropping will at most have a marginally > useful impact. > > Since Mark has started working on doing a single release of scikit-image > supporting Python 3.9 ( > https://github.com/scikit-image/scikit-image/pull/7412), perhaps we can > close the book on this request now, and decide to not change anything? > I.e., we do release with 3.9 support as planned. > > Cheers, > Ralf > > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: b.sipocz+numpyl...@gmail.com > ___ NumPy-Discussion mailing
[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Fri, May 10, 2024 at 8:47 AM Ralf Gommers wrote: > > > On Thu, May 9, 2024 at 12:28 AM Thomas Caswell wrote: > >> I think the spirit of NEP 29 is to pick your supported Python's when you >> pick a target release date and you should then stick to it (to avoid "we >> delayed so long we are over a cliff" decisions like this one). >> > > That's true I believe. > > >> We did NEP29 around the same time that Python went from 18 to 12 month >> releases (my memory is that the cadence change was being considered but not >> set). If Python is targeting an 18mo release cycle, then a 36mo window + >> 2mo delayed Python release could land you in only supporting one version of >> Python which seems too few (again, my memory could be a bit off). I was >> not at the meeting where SPEC 0 was discussed, >> > > Same here, I wasn't at that meeting so am unsure. I only got added to SPEC > 0 as a co-author at the end because it's mostly a copy of NEP 29. "change > in release cycle" is probably right as the motivation though. > > >> but I suspect that the narrowing is to better align with an integer >> number of Python releases while always hitting at least 2 versions of >> Python. >> > > At least 3, right? 36 months is always 3 minor versions. > > > >> >> >> It is worth considering that CPython has both a concept of "bugfix" >> (which is 18mo) and "security" (which is 42mo and source-only) support. It >> is arguable that by having "new feature" support and binary release >> targeting a given version of Python for 36mo we are supporting a given >> minor version of Python longer than upstream [speaking for myself I would >> sign onto a proposal to do security release against the last version of our >> libraries for all versions of Python that still have security support]. >> >> >> >> > So only 30% of users have Python 3.10+ or newer. Most smaller or newer >> projects can more than double their user base by supporting 3.8+. I could >> even argue that 3.7+ is still helpful for a new project. Once a library is >> large and stable, then it can go higher, even 3.13+ and not hurt anyone >> unless there's a major development. >> >> I have the exact opposite view of Henry here, I think for new projects >> you should be very aggressive and only support the newest Python version as >> you don't have any users (so do not have to be responsible yet)! >> > > I think what you do as a new project author totally depends on your goals > and priorities. Either way, the argument that only so few users "have a new > Python" seems a bit off-target. That's not how people think - they look for > new packages to use when they need functionality, and once they find > something that fits their needs, they make it work. Nor are the statistics > reflective of usage needs, especially for manylinux - it's more that > production deployments stay on the same version of Python for their own > lifetime I suspect. But such deployments also pin all their dependencies, > so they're irrelevant to new versions/projects. > > It gets ever-easier to install new Python versions, with pyenv/conda/etc. > The "my single Python install comes from python.org and I'm using the > same one because I am afraid to upgrade" is much less of an issue than it > was 10 years ago. And it's caused mostly by users having knowledge gaps. So > yes it can be a pain for them, but they'll have to learn at some point > anyway. Same for "my old HPC cluster uses ..." - it's often an even older > Python anyway, and you'll have tons of reasons why you don't want your > cluster-installed stack - learn to use Spack or Conda, and you'll be much > happier in the long run. > > --- > > Back to the topic of dropping 3.9 here: there seem to be some minor > concerns. Tom is right about the spirit of NEP29/SPEC0. And Sebastian is > partially right I think: not about `pip install scipy-image==0.22`, because > that should be picking 0.22.1 plus an older numpy; but `==0.22.0` instead > cannot be fixed anyway, and that's perhaps a more common way of spelling an > `==` constraint. So the last-minute dropping will at most have a marginally > useful impact. > > Since Mark has started working on doing a single release of scikit-image > supporting Python 3.9 ( > https://github.com/scikit-image/scikit-image/pull/7412), perhaps we can > close the book on this request now, and decide to not change anything? > I.e., we do release with 3.9 support as planned. > > I'll add that numpy 2.1.0 should follow a few months after 2.0.0. Normally, it would be released in June without Python 3.9 support, but due to the extended release cycle needed to get 2.0.0 out, it will be delayed. Current policy is that we always support at least three Python versions, but because we are not synced with Python, we end up with four. For instance, 2.1.0 will support three versions on release (3.10-3.12), but will finish with four after Python 3.13 is released. The current difficulty is unique to the breaking changes in 2.0.0
[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Thu, May 9, 2024 at 12:28 AM Thomas Caswell wrote: > I think the spirit of NEP 29 is to pick your supported Python's when you > pick a target release date and you should then stick to it (to avoid "we > delayed so long we are over a cliff" decisions like this one). > That's true I believe. > We did NEP29 around the same time that Python went from 18 to 12 month > releases (my memory is that the cadence change was being considered but not > set). If Python is targeting an 18mo release cycle, then a 36mo window + > 2mo delayed Python release could land you in only supporting one version of > Python which seems too few (again, my memory could be a bit off). I was > not at the meeting where SPEC 0 was discussed, > Same here, I wasn't at that meeting so am unsure. I only got added to SPEC 0 as a co-author at the end because it's mostly a copy of NEP 29. "change in release cycle" is probably right as the motivation though. > but I suspect that the narrowing is to better align with an integer number > of Python releases while always hitting at least 2 versions of Python. > At least 3, right? 36 months is always 3 minor versions. > > > It is worth considering that CPython has both a concept of "bugfix" (which > is 18mo) and "security" (which is 42mo and source-only) support. It is > arguable that by having "new feature" support and binary release > targeting a given version of Python for 36mo we are supporting a given > minor version of Python longer than upstream [speaking for myself I would > sign onto a proposal to do security release against the last version of our > libraries for all versions of Python that still have security support]. > > > > > So only 30% of users have Python 3.10+ or newer. Most smaller or newer > projects can more than double their user base by supporting 3.8+. I could > even argue that 3.7+ is still helpful for a new project. Once a library is > large and stable, then it can go higher, even 3.13+ and not hurt anyone > unless there's a major development. > > I have the exact opposite view of Henry here, I think for new projects you > should be very aggressive and only support the newest Python version as you > don't have any users (so do not have to be responsible yet)! > I think what you do as a new project author totally depends on your goals and priorities. Either way, the argument that only so few users "have a new Python" seems a bit off-target. That's not how people think - they look for new packages to use when they need functionality, and once they find something that fits their needs, they make it work. Nor are the statistics reflective of usage needs, especially for manylinux - it's more that production deployments stay on the same version of Python for their own lifetime I suspect. But such deployments also pin all their dependencies, so they're irrelevant to new versions/projects. It gets ever-easier to install new Python versions, with pyenv/conda/etc. The "my single Python install comes from python.org and I'm using the same one because I am afraid to upgrade" is much less of an issue than it was 10 years ago. And it's caused mostly by users having knowledge gaps. So yes it can be a pain for them, but they'll have to learn at some point anyway. Same for "my old HPC cluster uses ..." - it's often an even older Python anyway, and you'll have tons of reasons why you don't want your cluster-installed stack - learn to use Spack or Conda, and you'll be much happier in the long run. --- Back to the topic of dropping 3.9 here: there seem to be some minor concerns. Tom is right about the spirit of NEP29/SPEC0. And Sebastian is partially right I think: not about `pip install scipy-image==0.22`, because that should be picking 0.22.1 plus an older numpy; but `==0.22.0` instead cannot be fixed anyway, and that's perhaps a more common way of spelling an `==` constraint. So the last-minute dropping will at most have a marginally useful impact. Since Mark has started working on doing a single release of scikit-image supporting Python 3.9 ( https://github.com/scikit-image/scikit-image/pull/7412), perhaps we can close the book on this request now, and decide to not change anything? I.e., we do release with 3.9 support as planned. Cheers, Ralf ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
