You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scipy has already dropped 3.10, so I assume we can here? Also, judging by the progress on this repo, it's unlikely there will be a 1.0 release for October when I imagine scipy will drop 3.11. So, might as well also drop 3.11?
I see. I think a low-level provider library like this one here should strive to support as many old and even unsupported Python versions as humanly possible, because every version you drop at the top of the dependency chain ripples all the way down to the bottom, and ultimately end users.
Case in point, we just had to remove Python 3.10 support in glass-dev/glass#1093 for no other reason than array-api-extra dropping Python 3.10 support, and it's caused real pain for a small number of users. Python versions unfortunately have a very long tail in science.
array-api-extra has been following scikit-learn's lead on supported Python versions. If GLASS were to decide on a policy that is more conservative than sklearn going forward, I would be happy in principle for array-api-extra to follow and provide that support.
I am still hoping for scientific-python/specs#389 to materialise to give us a standardised longer support window than SPEC 0 as is.
Now for array-api-typing, given the early stage of development, I think it would be best to get off the ground using any features of recent Python versions that ease the process — that could be followed by work on backporting to older versions once there is a push for adoption.
I am still hoping for scientific-python/specs#389 to materialise to give us a standardised longer support window than SPEC 0 as is.
SPEC 0 LTS (plus one year) aligns with what I was suggesting in the issue: Drop 3.10 now and drop 3.11 in October (which essentially means that you can drop both now since this project won't release until October).
dropping Python 3.10 support, and it's caused real pain for a small number of users.
In what way? And why do they need the newest features of your library, but aren't able to upgrade Python?
In what way? And why do they need the newest features of your library, but aren't able to upgrade Python?
The newest features of my library are often developed for specific users. And those same users might be bound to use Python 3.9 because that's the last version supported by some hyper-specific bit of code developed by a PDRA a number of years ago that will never be updated. Pretty par for the course, I'd say.
developed by a PDRA a number of years ago that will never be updated. Pretty par for the course, I'd say.
Thanks for explaining 😄. Honestly, depending on a library like this is horrifying (especially since Python 3.9 is end-of-life—no one should feel obligated to support it anymore).
I wonder if the situation has changed today with LLMs writing so much code. I was able to break my dependency on tensorflow-probability (which is slow to fix bugs or do releases) by having codex write these two functions.
Anyway, I think there needs to be some kind of balance between supporting older versions and dropping them. As it stands, this library has been stopped for literally years because developers understandably can't find time to work on it.
I also think that given that this is a completely optional (unlike array-api-compat), if people are stuck in Python 3.9, they don't need to use the annotations. I think that's just a reasonable sacrifice you make if you can't or won't upgrade. Not everyone can have everything they want.
I propose we get things done as quickly as possible using the new features, and then if there is enough demand from old versions, we can consider broadening version support. And if this takes another couple years, it won't even matter since the "new" features we used won't even be new anymore.
Activity
ntessore commentedon Jun 9, 2026
I have no stake in this, but why drop support for versions that can be supported with little or no effort?
jorenham commentedon Jun 9, 2026
dropping 3.11 would allow us to use PEP 695 syntax
ntessore commentedon Jun 9, 2026
I see. I think a low-level provider library like this one here should strive to support as many old and even unsupported Python versions as humanly possible, because every version you drop at the top of the dependency chain ripples all the way down to the bottom, and ultimately end users.
Case in point, we just had to remove Python 3.10 support in glass-dev/glass#1093 for no other reason than array-api-extra dropping Python 3.10 support, and it's caused real pain for a small number of users. Python versions unfortunately have a very long tail in science.
lucascolley commentedon Jun 9, 2026
array-api-extra has been following scikit-learn's lead on supported Python versions. If GLASS were to decide on a policy that is more conservative than sklearn going forward, I would be happy in principle for array-api-extra to follow and provide that support.
I am still hoping for scientific-python/specs#389 to materialise to give us a standardised longer support window than SPEC 0 as is.
Now for array-api-typing, given the early stage of development, I think it would be best to get off the ground using any features of recent Python versions that ease the process — that could be followed by work on backporting to older versions once there is a push for adoption.
NeilGirdhar commentedon Jun 9, 2026
SPEC 0 LTS (plus one year) aligns with what I was suggesting in the issue: Drop 3.10 now and drop 3.11 in October (which essentially means that you can drop both now since this project won't release until October).
In what way? And why do they need the newest features of your library, but aren't able to upgrade Python?
ntessore commentedon Jun 11, 2026
The newest features of my library are often developed for specific users. And those same users might be bound to use Python 3.9 because that's the last version supported by some hyper-specific bit of code developed by a PDRA a number of years ago that will never be updated. Pretty par for the course, I'd say.
NeilGirdhar commentedon Jun 11, 2026
Thanks for explaining 😄. Honestly, depending on a library like this is horrifying (especially since Python 3.9 is end-of-life—no one should feel obligated to support it anymore).
I wonder if the situation has changed today with LLMs writing so much code. I was able to break my dependency on
tensorflow-probability(which is slow to fix bugs or do releases) by having codex write these two functions.Anyway, I think there needs to be some kind of balance between supporting older versions and dropping them. As it stands, this library has been stopped for literally years because developers understandably can't find time to work on it.
I also think that given that this is a completely optional (unlike
array-api-compat), if people are stuck in Python 3.9, they don't need to use the annotations. I think that's just a reasonable sacrifice you make if you can't or won't upgrade. Not everyone can have everything they want.I propose we get things done as quickly as possible using the new features, and then if there is enough demand from old versions, we can consider broadening version support. And if this takes another couple years, it won't even matter since the "new" features we used won't even be new anymore.