REL: Drop Python 3.10 as per SPEC 0 #140
Comments
|
Yes, I'm trying to follow SPEC 0—the lower bound is set at 3.10: array-api-extra/pyproject.toml Line 14 in a71bd2e The complication is that scikit-learn hasn't dropped 3.9 yet, and I have a PR up to vendor this library over there—scikit-learn/scikit-learn#30340. |
|
So we should also look at dropping 3.10 once we have dropped the unofficial 3.9 support—but ideally we get a version vendored in scikit-learn before moving forwards with that. |
Am I misreading SPEC 0? It says that 3.10 should have been dropped on October 1, 2024.
What does scikit-learn have to do with when you drop versions? All that will happen is that scikit-learn users who stick want to keep using 3.9 will get a modern version of scikit-learn and an old version of this project. |
|
I don't think there's much of an upside of dropping 3.10, it's a minor amount of maintenance work. The downside is larger though. This project doesn't need to follow SPEC 0, and probably shouldn't unless scikit-learn changes its mind on that. Remember that SPEC 0 is a recommendation only, and quite a few people/projects aren't convinced by it because it's pretty aggressive. |
I would at least like to merge any changes needed for scikit-learn/scikit-learn#30340 to be approved before we move forwards with making changes which will break scikit-learn. After that it is about finding a compromise between making development nice here vs not dropping so aggressively that scikit-learn has to wait a while before it can get new array-api-extra features/fixes. (It may well be as Ralf is suggesting that we should just support versions as long as they support them, to make the vendoring seamless. But I would like to push them along if we can :) ) |
|
Got it, I'll update my PR then to accommodate 3.10. It does feel like the more projects ignore SPEC0, the more unnecessary development work builds up. I'm not sure the benefit to users is larger than the development work involved. |
I don't think that that is the case. The main point is that for projects with compiled code, which have to release a whole bunch of extra wheels per Python version, and in case of things not supported by Python 3.10, there is quite a bit of extra maintenance work. And each time per NEP 29 / SPEC 0, the discussions on dropping a Python version were a pain. So those docs give one license to do the dropping more easily. For this project, which is small and pure Python, there's little overhead in supporting older Python versions. Not zero, but really quite minimal compared to supporting different versions of various array libraries. Scikit-learn gets to make its own trade-offs obviously - there's a bunch of devs there that need to run on old clusters where they want to use the cluster-provided Python, which was always their main reason for not dropping. Now I personally don't think that that's the most compelling reason, but there's little point arguing about it - it's their call. |
Sorry, I don't understand this point. No matter how many releases you support, the average long term cadence at which you drop Python versions is necessarily 1/year. Similarly, the cadence at which you support new Python versions is 1/year.
Yes, sure. But I think there's a benefit to the whole ecosystem moving together. I think some of the problems of projects lagging go unstated. Yes, there's added maintenance work. There's also code that's unnecessarily hard to read (e.g., when 3.12 comes out, PEP 695 will make generics a lot easier to read). And even when people implement their research and make it available—it's a lot harder to read if they aren't nudged by the ecosystem to write it in a modern way.
I understand that. I've had to do that too, but what I ended up doing is just adding a virtual environment. If someone doesn't want to do that, then do they really need the latest version of scientific libraries?
Right. |
The point is not that it's effort to do the dropping - that's pretty easy. The main effort is keeping ~8 extra wheel build jobs per Python version working continuously - this effort is significant for complex projects like NumPy, SciPy, scikit-learn, Matplotlib, etc. (maintainers of those projects authored SPEC 0). |
|
Oh, I misunderstood. I thought your point there was against following SPEC0. My mistake. Yes, I see your point about wheels as the (main?) motivation for SPEC0. |
|
I've always interpreted NEP29 / SPEC0 as being free to drop a supported version when it becomes inconvenient to continue maintaining it, without needing to call for a formal decision by committee every time. It should not be intended as being forced to drop a version as soon as its time is up. Case in point, it is now very inconvenient to continue maintaining Python 3.9. There are many code cleanups that could happen if we remove it. I disagree with informally supporting it while not testing it on CI, as it makes some coding decisions quite obscure and almost certain to break downstream. Also, many of the libraries we are testing against have long dropped it, so deploying Python 3.9 in means automatically and quielty also deploying obsolete versions of the best part of the libraries we integrate against - with the almost certainty that some things will go badly. On the other hand, I see zero benefit in dropping Python 3.10 now. |
|
Now that scikit-learn have written down some rules to follow, I think we can close this as not planned. The plan going forwards will be to support versions as long as scikit-learn does. The hope is that SPEC 0 will eventually accommodate for this in a more standardised way. |
Does this project follow SPEC 0? If so, can we drop Python 3.10?
The text was updated successfully, but these errors were encountered: