Reinstate support for Python 3.10 and 3.11

[crusaderky]

With #115, you can no longer call np.asarray(x), where x is a array_api_strict.Array, on Python 3.10 and 3.11.
This effectively means that array-api-strict is no longer fit for purpose on 3.10 and 3.11.

This minimum version bump is reflected in the release notes, but

• not in pyproject.toml
• nor in the conda-forge recipe https://github.com/conda-forge/array-api-strict-feedstock/blob/main/recipe/recipe.yaml

As a result, all projects that don't pin array-api-strict will break or have already broken.
All projects that have it as a hard dependency in their test suite (why wouldn't they? it's tiny!) break and fixing them is potentially going to require substantial effort.

I don't think this was discussed widely enough, and I, for one, am strongly convinced this was a very bad decision.

SPEC0 dropped support for 3.10 in Q4 2024 and requires 3.11 to be supported until Q4 2025.
Most projects do not aggressively enforce SPEC0. We can see some of the biggest users of array-api-strict below:

library	Minimum Python version
array-api-compat	3.10
array-api-extra	3.10
scipy 1.17	3.11
scikit-learn	3.10

Proposed course of action

Option 1

• Yank release 2.4;
• Amend ENH: rm __array__, add __buffer__ #115 so that it defines __array__ on Python 3.10 and 3.11, and defines __buffer__ instead on newer versions;
• Reinstate CI on 3.10 and 3.11;
• Issue release 2.5.

Option 2

• Yank release 2.4;
• Amend pyproject.toml to prevent pypi users on Python 3.10-3.11 from upgrading;
• Issue release 2.4.1;
• Amend conda-forge recipe to prevent conda users from upgrading.

I strongly prefer option 1, on the basis that the users listed above would get long term harm from n.2. They won't break immediately, but will have to deal with either diverging versions of array-api-strict or changing array-api-strict to be a fully optional test dependency.

Note that Option 2 is in violation of SPEC0 until Q4 2025.

[crusaderky]

CC @ev-br @lucascolley @betatim , who were involved in the original PR.

[lucascolley]

I would support Option 1

[betatim]

I'm generally in favour of supporting old versions until you can think of a reason not to. And "time passing" isn't generally a reason. This means I'd be happy with option 1.

That being said, in scikit-learn the current state of affairs doesn't cause a problem. Yes you can use scikit-learn with python 3.10 but we don't expect users of scikit-learn to use array-api-strict. This library exists to test other libraries. In the CI where we use array-api-strict we use a newer version of Python and I can't think of a reason why we'd have to test with an older one.

Given that the current state of affairs doesn't cause a problem, I think option 2 would also be fine and be less complicated (no version dependent code)? How do the other libraries that use array-api-strict use it? Is the current lack of Python 3.10/.11 support a problem for them?

[ev-br]

#115 has been open from December, has been discussed multiple times in the array API community meetings. Scipy and scikit-learn were fixed to prepare for this change, and see no problems. What downstreams are problematic, other than array-api-extra?

TL;DR : option 3 is to fix array-api-extra instead of starting with requiring more work yanking the array-api-strict release

[crusaderky]

What downstreams are problematic, other than array-api-extra?

I do not know the full inventory of downstream users.

TL;DR : option 3 is to fix array-api-extra instead of starting with requiring more work yanking the array-api-strict release

No, I do not think it is acceptable to throw all present and future users that support 3.10 - 3.11 under the bus unless they spend time figuring out what's wrong with array-api-strict. Preventing pypi and conda from upgrading (option 2) is IMHO the bare minimum we should do.

[ev-br]

Like I was saying: this was widely discussed since at least least six months. And now all of a sudden it's "unacceptable" out of the blue. Sorry, no, you can't just list your options 1 and 2 without option 3 :-).

[crusaderky]

On https://hackmd.io/zn5bvdZTQIeJmb3RW1B-8g?view I can only find one discussion about it, on https://hackmd.io/zn5bvdZTQIeJmb3RW1B-8g?view#Meeting-minutes-14-November-2024, and I can't find any deliberation that array-api-strict shall drop 3.10 and 3.11 support. Only a mention that __buffer__ requires 3.12 on pure Python.

Even if it was explicitly deliberated, yet not recorded, that array-api-strict should drop 3.10 and 3.11 early because of this (and if you confirm it was, I will not challenge it further), I have the strong suspicion that it was never discussed that Python 3.10-3.11 users will suddenly have their CI start failing because they installed a release that is not compatible with their environment.

[betatim]

IMHO the mistake was not setting the requirements of the package for the 2.4 release. Let's fix that. The actual change seemed to have good support (from the known users).

I think most users of array-api-strict use the latest released version and most of them don't use the oldest possible version of Python. This means that the probability for someone to be using not the latest released version and using Python 3.10 is small. From that point of view I think it would be fine to fix up the requirements specification and make a new release. Eventually we can yank 2.4 - but only "eventually" to give projects time to transition. For example for scikit-learn I can't configure the CI to use 2.4.1 without it existing, so if we yank 2.4 at the same time as releasing 2.4.1 I'd have to spring into action at "just the right time" to update the CI. Which seems unnecessary for this.

[crusaderky]

For example for scikit-learn I can't configure the CI to use 2.4.1 without it existing, so if we yank 2.4 at the same time as releasing 2.4.1 I'd have to spring into action at "just the right time" to update the CI. Which seems unnecessary for this.

The idea of yanking is that your CI will automatically revert to 2.3.x if it's not pinned.
Which is particularly important for any 3.10-3.11 CI.

[betatim]

The idea of yanking is that your CI will automatically revert to 2.3.x if it's not pinned.
Which is particularly important for any 3.10-3.11 CI.

We use lockfiles for the CI environments to prevent "ground shifting" under us. One drawback is that you can only re-lock the env once a new version exists. Going back to 2.3 seems worse than continuing to use 2.4

[Saransh-cpp]

FYI: now one cannot use the np.testing module for comparing array-api-strict arrays (because np.testing functions use np.asarray internally), and the array-api-extra testing functionalities are private (data-apis/array-api-extra#17). So, now there is no right way of testing code with array-api-strict (AFAIK)?

PS: our array-api-strict tests are failing and I think the only way to make them pass is to use the private methods from array-api-extra (or invent our custom assert_* functions).

[lucascolley]

FYI: now one cannot use the np.testing module for comparing array-api-strict arrays (because np.testing functions use np.asarray internally)

This is for Python <3.12, right?

If so, the discussion above is debating whether this capability should be reinstated for Python <3.12 using __array__, or whether all testing with array-api-strict should only be done on Python 3.12+.

I am happy either way tbh, but I definitely prefer the former as it makes it easier for users to define 'min-dependencies' test envs for their projects.

If we go with the latter, I agree with @crusaderky that 2.4 should still be yanked, as https://github.com/data-apis/array-api-strict/blob/main/pyproject.toml#L8 is inaccurate if 3.12 is required.