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 <asmeu...@gmail.com> wrote: > On Tue, May 7, 2024 at 6:03 AM Henry Schreiner <henr...@princeton.edu> > 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: tcasw...@gmail.com > -- Thomas Caswell tcasw...@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
