Repository navigation
Drop Python 3.11 #18736
Description
Python 3.14 is out now. And SPEC 0 might recommend it "soon"? How about v8.0? Is that too soon? If so, when?
Related:
Python 3.14 is out now. And SPEC 0 might recommend it "soon"? How about v8.0? Is that too soon? If so, when?
Related:
Activity
tepickering commentedon Oct 16, 2025
my take is that as long as the codebase still supports 3.11, the PSF still supports 3.11, and there's no significant extra cost to supporting it (extra CI test fine, but no code workarounds), we might as well say we support it. if any of those conditions change, then i'd say we drop at that point.
pllim commentedon Oct 16, 2025
If you want to wait till its EOL, I think it is Oct 2027 (2 more years at the time of writing) according to https://peps.python.org/pep-0664/
mhvk commentedon Oct 16, 2025
There's nothing super-specific, but there are a couple of doctest and dependencies that have
PYTHON_LT_3_12markers.Overall, though, I would just stick with SPEC 0: the whole point of having that specification is not have to argue about it. That means 7.2 would still support 3.11 (just barely), and 8.0 would move to >=3.12. Presumably numpy and/or scipy will do something similar.
neutrinoceros commentedon Oct 16, 2025
That's not my interpretation of it; I see adherence to SPEC 0 as a mean to justify the earliest possible date for dropping Python versions, not as a commitment to do so. We've seen many users encountering issues that were already fixed in astropy versions they just couldn't upgrade to, because they did not control the Python version they had access to.
If we were still compiling one wheel per platform and per Python version, there would be an argument for dropping early so we could keep the build matrix's size reasonable, but with abi3 wheels we can now support more versions at no cost on this side. Overall I think we could easily, and should, be more conservative than what SPEC 0 allows. The gain of dropping 3.11 now (or soon) is marginal, and only benefits us maintenance, but the cost is important, and would be mostly paid by users. That's not the kind of trade of we should be making lightly, and especially not without discussion.
neutrinoceros commentedon Oct 16, 2025
(numpy and scipy are much harder to support on a large version range, so I don't think it's justified for us to follow the same pace)
pllim commentedon Oct 17, 2025
Here is numpy's plan: "[T]he numpy 2.4.x series will support 3.11 but we’ll drop it for 2.5. 2.5.0 comes out next June [2026]."
So I think what this means is that we can stick with Python 3.11 until we have to bump numpy minversion to 2.5, which isn't even on SPEC 0's radar yet.
neutrinoceros commentedon Oct 17, 2025
It usually happens the other way around though; meaning, our oldest supported Python implies a lower bound on NumPy versions we can support. For instance it'll be impossible to preserve support for NumPy 1.x once we drop Python 3.12.
pllim commentedon Oct 17, 2025
Well, if people want a good reason to drop Python 3.11, when numpy drops it and that becomes our minversion is a pretty good reason. 🤷♀️
pllim commentedon Oct 17, 2025
Or when Python 3.11 reaches EOL, which is definitely a very good reason.
hugovk commentedon Oct 17, 2025
Only in a very limited way: security only, source only (no binary installers), and only released as needed.
https://devguide.python.org/versions/#status-key
neutrinoceros commentedon Oct 17, 2025
definitely. Alls I'm saying is that I'm betting this won't happen in the next 2 years, at which point we don't need a better reason to drop 3.11 if we're still supporting it by then.
mhvk commentedon Oct 17, 2025
I really don't understand why we are trying to hang on to older versions of python. For dropping python 3.10 almost exactly a year ago, we didn't hesitate (#16900), and also for that release it was not like it was a big deal that we could remove the wrapper code we had already created for
add_exception. Also, maybe I missed it, but I don't recall hearing complaints about our lack of continued support for python, so I don't understand who would actually benefit (i.e., wanting latest astropy, but unable to upgrade python).Anyway, please let's just stick with the automatic schedule implied by SPEC 0, just as we do for our other main dependency, numpy.
neutrinoceros commentedon Oct 17, 2025
Exactly. In hindsight, I believe this was a mistake, which is why I'm trying to slow down the pace we're currently running at.
I think Brigitta was the one who brought up some users felt left behind, but I also experienced some of that first hand on Slack, with users unable to upgrade astropy at all because they couldn't upgrade Python too.
And for what it's worth, I also don't think we should be taking SPEC 0 as a mandate to drop older versions of other dependencies, especially NumPy, where it would currently mean dropping anything older than 2.0, which we are still occasionally seeing incompatibilities with and which the larger share of the (non core) scientific Python ecosystem isn't fully supporting yet.
mhvk commentedon Oct 17, 2025
OK, I definitely don't want to dismiss actual problems -- ping @bsipocz to get her input -- I really just want not to have to spend time thinking about this. So, if we make a decision to continue supporting older python until EOL by default (i.e., unless something truly important is up), then we should state that (preferably in a public place; resurrect the relevant APE?).
bsipocz commentedon Oct 17, 2025
I can't recall I was complaining about the pace --and I definitely don't say EOL should be supported. Some users may indeed be left behind, but as Marten says if they cannot get the latest release because of their older python version that shouldn't be such a big deal.
What I may have mentioned is that I do not plan to drop support following SPEC0 for astroquery, but that is because of astroquery's special place -- unlike for astropy or frankly, for most other libraries, we cannot expect that old versions will work if installed with e.g. pypi-timemachine. But I do not plan to keep an LTS version for backporting fixes server side changes, instead just don't actively drop support for python/numpy/astropy versions as fast as SPEC0 therefore enabling practically everyone to be able to use the latest release or dev version.
neutrinoceros commentedon Oct 17, 2025
Whoops, I must be misremembering, thank you clarifying.
Awesome, that's exactly what I'm pushing for here !