[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Mon, 2024-05-06 at 22:39 +, Henry Schreiner wrote: > This will be messier for projects building wheels and wanting to > support non-EoL Python versions. To build a wheel with anything other > than pybind11, you now need the oldest supported NumPy for Python < > 3.9, the latest NumPy 1 for Python 3.9, and NumPy 2 for Python 3.10+. > I don't know if that's important in the decision, but thought I'd > point it out. Also, according to NEP 29, 3.10+ only became the > requirement a couple of weeks ago, while it has been months since > SPEC 0 dropped it. I don't think either document really details what > to do when there's a really long development cycle that spans a > cutoff date. FWIW, I have heard similar opinions now. Supporting a stack of libraries for all non-EoL Python versions is harder if NumPy must be different. The biggest problem would be if you end up with full support for only NumPy 1 or NumPy 2 (i.e. similar to what numba has to do due to promotion). I hope that is rare enough that it doesn't matter, but I can't say I am sure. (And yeah, if that happens, we might see the ask of downstream to support 3.9 and NumPy 2 in a release. And trying to avoid that was part of why the discussion started I think.) - Sebastian > > If you drop 3.9 from the metadata, I don't think there's any need to > secretly keep support. It's too hard to actually use it, and it's not > guaranteed to work; it would be better to just tell anyone needing > 3.9 to use a beta version when it was still supported. > > (Rant below) > > To be fair, I've never understood NEP 29's need to limit Python > versions to 42 months after the 2.7 issue was resolved with official > Python EoL. Now there's a standard (60 months, exactly 5 versions), > and almost all the rest of the ecosystem supports it. This just > wedges a divide in the ecosystem between "scientific" and "everyone > else". It makes me have to think "is this a scientific Python > project? Or a general Python project?" when I really shouldn't have > to on every project. > > I really didn't understand SPEC 0's _tightening_ it to 36 months (and > I was at the developer summit where this was decided, and stated I > was interested in being involved in this, but was never included in > any discussion on it, so not sure how this was even decided). > Dropping Python doesn't hurt projects that are mostly stable, but > ones that are not are really hurt by it. Python 3.8 is still heavily > used; people don't mind that NumPy dropped 3.8 support because an > older version works fine. But if there's a major change, then it > makes smaller or new projects have to do extra work. > > Current numbers (as of May 4th) for downloads of manylinux wheels: > * 2.7: 2% > * 3.5: 0.3% > * 3.6: 7.4% > * 3.7: 20.4% > * 3.8: 23.0% > * 3.9: 15.3% > * 3.10: 20.8% > * 3.11: 8.4% > * 3.12: 2.3% > > 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. > > Little rant finished. :) > ___ > 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: sebast...@sipsolutions.net > ___ 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
[Numpy-discussion] Re: numpy on iOS
Thanks a lot! With new CPython 3.13 native mobile builds I hope the process could be simplified in future. ___ 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
[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
On Tue, May 7, 2024 at 6:03 AM Henry Schreiner wrote: > > This will be messier for projects building wheels and wanting to support > non-EoL Python versions. To build a wheel with anything other than pybind11, > you now need the oldest supported NumPy for Python < 3.9, the latest NumPy 1 > for Python 3.9, and NumPy 2 for Python 3.10+. I don't know if that's > important in the decision, but thought I'd point it out. Also, according to > NEP 29, 3.10+ only became the requirement a couple of weeks ago, while it has > been months since SPEC 0 dropped it. I don't think either document really > details what to do when there's a really long development cycle that spans a > cutoff date. > > If you drop 3.9 from the metadata, I don't think there's any need to secretly > keep support. It's too hard to actually use it, and it's not guaranteed to > work; it would be better to just tell anyone needing 3.9 to use a beta > version when it was still supported. > > (Rant below) > > To be fair, I've never understood NEP 29's need to limit Python versions to > 42 months after the 2.7 issue was resolved with official Python EoL. Now > there's a standard (60 months, exactly 5 versions), and almost all the rest > of the ecosystem supports it. This just wedges a divide in the ecosystem > between "scientific" and "everyone else". It makes me have to think "is this > a scientific Python project? Or a general Python project?" when I really > shouldn't have to on every project. > > I really didn't understand SPEC 0's _tightening_ it to 36 months (and I was > at the developer summit where this was decided, and stated I was interested > in being involved in this, but was never included in any discussion on it, so > not sure how this was even decided). Dropping Python doesn't hurt projects > that are mostly stable, but ones that are not are really hurt by it. Python > 3.8 is still heavily used; people don't mind that NumPy dropped 3.8 support > because an older version works fine. But if there's a major change, then it > makes smaller or new projects have to do extra work. I was never part of this discussion, but I totally support tightening the support window. Supporting more Python versions is not free for projects. Every version supported is another multiple in the CI matrix, and if your support window is X years that means you have to wait X years to use any new Python feature. The real issue here is Python's ridiculous faster release cadence. If package maintainers don't want to support 5 Python versions at once, then maybe that's a sign that CPython shouldn't either. I'll make the same argument now that I made in 2016 about dropping 2.7 support https://www.asmeurer.com/blog/posts/moving-away-from-python-2/. If users want to use older versions of Python, that's their prerogative, but they then have no reason to also expect to be able to use the latest versions of libraries. Aaron Meurer > > Current numbers (as of May 4th) for downloads of manylinux wheels: > * 2.7: 2% > * 3.5: 0.3% > * 3.6: 7.4% > * 3.7: 20.4% > * 3.8: 23.0% > * 3.9: 15.3% > * 3.10: 20.8% > * 3.11: 8.4% > * 3.12: 2.3% > > 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. > > Little rant finished. :) > ___ > 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: asmeu...@gmail.com ___ 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
[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0
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). 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, 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. 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)! A very bad idea: numpy2 should require py312 to buy us a bunch more time to practically work through these issues. Tom On Wed, May 8, 2024 at 5:27 PM Aaron Meurer wrote: > On Tue, May 7, 2024 at 6:03 AM Henry Schreiner > wrote: > > > > This will be messier for projects building wheels and wanting to support > non-EoL Python versions. To build a wheel with anything other than > pybind11, you now need the oldest supported NumPy for Python < 3.9, the > latest NumPy 1 for Python 3.9, and NumPy 2 for Python 3.10+. I don't know > if that's important in the decision, but thought I'd point it out. Also, > according to NEP 29, 3.10+ only became the requirement a couple of weeks > ago, while it has been months since SPEC 0 dropped it. I don't think either > document really details what to do when there's a really long development > cycle that spans a cutoff date. > > > > If you drop 3.9 from the metadata, I don't think there's any need to > secretly keep support. It's too hard to actually use it, and it's not > guaranteed to work; it would be better to just tell anyone needing 3.9 to > use a beta version when it was still supported. > > > > (Rant below) > > > > To be fair, I've never understood NEP 29's need to limit Python versions > to 42 months after the 2.7 issue was resolved with official Python EoL. Now > there's a standard (60 months, exactly 5 versions), and almost all the rest > of the ecosystem supports it. This just wedges a divide in the ecosystem > between "scientific" and "everyone else". It makes me have to think "is > this a scientific Python project? Or a general Python project?" when I > really shouldn't have to on every project. > > > > I really didn't understand SPEC 0's _tightening_ it to 36 months (and I > was at the developer summit where this was decided, and stated I was > interested in being involved in this, but was never included in any > discussion on it, so not sure how this was even decided). Dropping Python > doesn't hurt projects that are mostly stable, but ones that are not are > really hurt by it. Python 3.8 is still heavily used; people don't mind that > NumPy dropped 3.8 support because an older version works fine. But if > there's a major change, then it makes smaller or new projects have to do > extra work. > > I was never part of this discussion, but I totally support tightening > the support window. Supporting more Python versions is not free for > projects. Every version supported is another multiple in the CI > matrix, and if your support window is X years that means you have to > wait X years to use any new Python feature. > > The real issue here is Python's ridiculous faster release cadence. If > package maintainers don't want to support 5 Python versions at once, > then maybe that's a sign that CPython shouldn't either. > > I'll make the same argument now that I made in 2016 about dropping 2.7 > support https://www.asmeurer.com/blog/posts/moving-away-from-python-2/. > If users want to use older versions of Python, that's their > prerogative, but they then have no reason to also expect to be able to > use the latest versions of libraries. > > Aaron Meurer > >
