Drop python 3.11?

EDIT: following discussion in #20228, this issue is now considered to be mostly about python, and will be closed by #20228. We can have a separate discussion about numpy in #20274.

For 8.1, according to SPEC 0, we could/should drop python 3.11 and numpy 2.0 (and presumably others).

For #20183, dropping python 3.11 may be handy (though I may be able to work around it).

RFC: reminder to remove PyINCREF(Py_None) when support for Python 3.11 is dropped #18229
PERF: use scaler class instead of lambda for unit scale conversions #20183

+1

Also I think we need to ask around if downstream, especially pipelines, are okay with this.

I think this one is a bit more concrete about the here and now, so not a duplicate in that sense... There are some 40 lines of horrible hacky C that I could avoid in #20193 -- https://github.com/astropy/astropy/pull/20183/changes#diff-63d7ebd68a7864bd63aecaa615072a16d6d0fb6b4b2645107bd43dc95f4fd99aR12

Hmm, if it's by SPEC0, then astropy could consider endorsing the SPEC. There are a few other ones that are practically endorsable, e.g. the nightly wheels should not be controversial, and I suppose some of the other ones are also applicable and uncontroversial : https://scientific-python.org/specs/purpose-and-process/#endorsing-a-spec, https://scientific-python.org/specs/

If helps, I can do a short session at the coordination meeting about the SPEC process and purpose.

As usual, I tend to be against bumping minimal requirements prematurely, which I believe SPEC0 encourages us to do.
It's been almost 2 years since we dropped 3.10 . At this rate, we'd be dropping 3.12 about the time it'll be EOL, at which point I'd have no objection at all, so I could be persuaded that this is acceptable now.
However, I'm not seeing an argument in favor of dropping Numpy 2.0, which is not even 3 years old, besides "SPEC0 says we can". In my opinion, compliance (not violating the SPEC) is much more valuable than (potentially pointless) pro-active enforcement.

@bsipocz

@bsipocz - I think a session would be good. I keep not understanding why if someone can install a newer version of astropy, it is a problem to update other packages (python maybe a little, but that's why that has a longer timeline).

My own sense is that certainly if there is any PR that has to work around a dependency that could be dropped, the dependency should be dropped. For #20193, I spent a good 4 hours (at a cost of US$600 to astropy) making it work with python 3.11. This was before I realized it could be dropped, which to me is an argument to sticking to SPEC 0 closely for our major dependencies.

Another argument is for packages that build on astropy: they are basically stuck supporting older versions too, unless they are going to deviate from astropy (which then means they have to think about what dependencies of astropy they actually use, instead of just depending on those transitively).

Anyway, personally I'd prefer that once a release is made, we immediately drop the dependencies that will no longer be needed for the next one, so one can develop in the state the next release will be.

But for this particular issue, the question mostly is about python 3.11.

I spent a good 4 hours (at a cost of US$600 to astropy) making it work with python 3.11

there's an argument to be made that it'd be a waste not to ship the result. But I sympathise with wanting to get rid of it sooner rather than later.

Another argument is for packages that build on astropy: they are basically stuck supporting older versions too

I don't get this point.

which then means they have to think about what dependencies of astropy they actually use, instead of just depending on those transitively

I think the point we agree on is that we should restrict downstream as little as possible, but I believe this phrasing is showing of another fundamental point of divergence; I think it's never a good idea to "just depend" on, e.g., numpy transitively. If a package uses numpy directly (as most do), it should always declare it as a direct dependency and deal with its own support window(s). My conclusion from there is that the more fundamental a package, the wider a supported range for their own dependencies it should offer. Restrictions can grow tighter as we get further from the base of the stack.

personally I'd prefer that once a release is made, we immediately drop the dependencies that will no longer be needed for the next one, so one can develop in the state the next release will be

But it's generally not possible to anticipate what will actually be worth dropping. It seems to me that, taking your argument to an extreme, we could justify only ever supporting the very latest versions of numpy and astropy, which I hope we can agree isn't desirable.

Anyway, personally I'd prefer that once a release is made, we immediately drop the dependencies that will no longer be needed for the next one, so one can develop in the state the next release will be.

I strongly agree. The potential benefit of reducing development effort and literally saving project money is real. Even now, the recent PR #20130 includes code to deal with numpy < 2.1 ("currently on NumPy < 2.1 (where np.strings.zfill is buggy)"). Undoubtedly there was time spent discovering, understanding, and working around that bug. Had we already moved on then none of that effort would have been wasted.

Chandra operations uses astropy in mission critical code, and what is more important than supporting old versions is predictability of requirements. If astropy keeps supporting older dependencies for years and then suddenly brings dependency requirements to comply with SPEC 0, that would be more impacting than predictably staying up with SPEC 0 every release.

But it's generally not possible to anticipate what will actually be worth dropping.

That is exactly a feature of SPEC 0 - it defines a formula that you just evaluate for our dependencies and apply the results for each release so you don't need to guess. You are exactly right that it can be difficult to know if some package has a bug that is impacting to astropy (maybe even not obvious in tests), but the best way to mitigate that risk is keeping packages somewhat up to date.

taking your argument to an extreme

There is no slippery slope here. SPEC 0 is concrete about support duration and there has been no suggestion of violating that.

@pllim

Let's put it that way: if we anticipate additional and substantial effort will be needed to support 3.11 specifically after #20183, then I'm in favor of dropping support 3.11 on the dev branch. Otherwise, I'd rather we try to branch out 8.2.x first and then drop it.

The follow-up to #20183 would require more work for python 3.11, though it is one that where one can on the python side decide to not use it.

@pllim - the number of places where we check for python and numpy versions is not that big any more, so I am not very worried about backporting bugfixes. Also, IIRC, it is only 2 months more for 7.2 so probably just one more, final bug-fix release.

Re: Endorsing SPECs -- I think it should be a separate issue to keep the discussions here focused on dropping python/numpy versions.
I am not opposed to it but I never brought it up because I thought Scientific Python was mainly interested in endorsements from its own "core libraries".

We added some domain stacks recently astropy included. Some of these have endorsed SPECs already, and for some it makes little sense as they are big picture umbrella projects rather than individual libraries.

Here is the new issue for SPEC discussions:

Astropy should endorse SPEC 0 astropy-project#539

FWIW, numpy-dev requires python>=3.12, so numpy does follow SPEC 0 more closely.

Indeed. I don't really see why or how this would affect astropy though.

to put my two cents in as someone who maintains the calibration pipeline dependencies downstream; any constraints that upstream adopts will transfer to client packages downstream, so in my opinion it should be "what's the broadest set of versions a foundational library can support without a bunch of extra effort" (and I think astropy is definitely a foundational library)

@neutrinoceros

and I also agree with @neutrinoceros, ideally each package should determine what it can support independently

@zacharyburnett

@zacharyburnett - since I had a real confusion with @neutrinoceros, let me clarify: does your request hold for strong or weak astropy dependencies? Specifically, this is for numpy and python itself: is there ever a situation where you need to upgrade astropy but cannot upgrade numpy? There are now a number of PRs merged/in waiting which have to add work-arounds for numpy 2.0... (not by me for a change).

@zacharyburnett

@zacharyburnett - one other question: wouldn't life for you actually be easier if you knew years in advance when the next upgrades would happen? You would no longer have to check changelogs to see whether things are still in a consistent state.

does your request hold for strong or weak astropy dependencies? Specifically, this is for numpy and python itself: is there ever a situation where you need to upgrade astropy but cannot upgrade numpy?

wouldn't life for you actually be easier if you knew years in advance when the next upgrades would happen?

yes of course being on a schedule is good, but we do have users on older Python versions and every time an upstream package that we rely on for consistency of numerical results (astropy, numpy, scipy) deprecates a Python version, we have the following choice:

deprecate that Python as well and force users to install a new Python (which means users on older Pythons will just stop getting updates and won't know why unless they read the changelogs) or
keep supporting the previous version and allow some users on older Pythons to run into an issue of, for instance, getting an older version of astropy with a newer version of jwst (and not being able to reproduce the exact numerical results as STScI-provided calibrated data) without pip telling them they're actually not on the latest astropy

which is why, ideally, we would prefer to have dropping Python version support be as infrequent as possible. Of course, we also directly import and use numpy, so if numpy is dropping Pythons on a schedule anyway then it's sorta a moot point what astropy does, from the perspective of downstream and numerical consistency. I just think an individual package should have in its requires-python all the versions that it currently can support and can run on, not necessarily the versions that an upstream package constrains it to, until it starts using new features that aren't supported in the older language versions

Since numpy issue is now #20274 , I have updated the issue title here to be less confusing. This issue now only concerns Python minversion.

Navigation Menu

Repository navigation

Drop python 3.11? #20184

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Drop python 3.11? #20184

Description

Activity

nstarman commented on Aug 1, 2026

pllim commented on Aug 3, 2026

pllim commented on Aug 3, 2026

mhvk commented on Aug 4, 2026

bsipocz commented on Aug 4, 2026

neutrinoceros commented on Aug 4, 2026

mhvk commented on Aug 4, 2026

neutrinoceros commented on Aug 4, 2026

taldcroft commented on Aug 4, 2026

taldcroft commented on Aug 4, 2026

7 remaining items

mhvk commented on Aug 4, 2026

bsipocz commented on Aug 4, 2026

pllim commented on Aug 4, 2026

mhvk commented on Aug 7, 2026

neutrinoceros commented on Aug 7, 2026

zacharyburnett commented on Aug 11, 2026

zacharyburnett commented on Aug 11, 2026

mhvk commented on Aug 11, 2026

mhvk commented on Aug 11, 2026

zacharyburnett commented on Aug 11, 2026

pllim commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions