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: arch...@mail-archive.com

Reply via email to