Support for older versions of the standard

[asmeurer]

Should we support older versions of the standard?

I don't think there's any point to supporting 2021.12, since no implementation actually supports it (including array-api-compat). However, as libraries actually start implementing the standard, being able to support multiple versions here could be useful.

For now, we could just tell people to install older versions of array-api-strict. But if people actually test against old versions of the standard, I would much rather just support them at once here than trying to support backport versions.

Plus, the __array_namespace__ method has the version flag specifically for this sort of thing.

By the way, if you were to ask the same question for array-api-compat, or any actual implementation for that manner, I would say no, unless the standard ends up adopting some serious backwards incompatible changes in some future version. But there could be an argument for the strict implementation to have this.

[asmeurer]

Supporting this sort of thing would also make it easier to support draft changes to the standard alongside the most recent release.

[asmeurer]

This issue and #7 are basically the same thing. We need to figure out a way to present different versions of array-api-strict with different subsets of functions or behaviors, ideally in a way that minimizes code duplication and maintenance burden.

[asmeurer]

The naive way to do this would be to set a global flag. My worry though is that would break if you have multiple array consuming libraries in play at once. For instance, what if scikit-learn tests with array-api-strict but calls a scipy function, which also uses the array API. If scikit-learn requests, say, 2022.12 and scipy requests 2023.12, this would lead to an incompatibility.

So instead, I think we should create simple types.ModuleType namespace objects representing different array API versions. These would just be shallow copies of the normal array_api_strict namespace except namespaces for older versions would omit functions that shouldn't be there, and those functions would also automatically use older signatures, etc.

Importantly, it should work just fine to pass an Array object from one namespace to another, because they are just shallow copies, so the above scikit-learn/scipy use-case would work seamlessly.

The same would work for a data-dependent shapes mode (#7) or any other kind of mode. The namespace objects would just consist of some flags corresponding to enabled behaviors and the functions would automatically enable/disable those behaviors.

One question here is testing. Will the test suite always support older versions of the standard? I think as long as we always add tests for new functionality under if api_version >= '2023.12' guards it should work. I also need to check that the signature tests work correctly for older versions. Any thoughts @honno?

[honno]

+1 generally, covering and testing multiple versions would be great for the test suite.

I think we should create simple types.ModuleType namespace objects representing different array API versions. These would just be shallow copies of the normal array_api_strict namespace except namespaces for older versions would omit functions that shouldn't be there, and those functions would also automatically use older signatures, etc.

data-apis/array-api#589 might be interesting here.

One question here is testing. Will the test suite always support older versions of the standard? I think as long as we always add tests for new functionality under if api_version >= '2023.12' guards it should work.

I think so, yes. api_version guards in the test suite work mostly ok—I'm not a fan of the few test functions defined in if statements is all.¹

Footnotes

1. Which seemed necessary because of using unavailable Hypothesis APIs otherwise, which we could just wrap... ↩

[asmeurer]

data-apis/array-api#589

I'll have to think about this. Actually typing isn't something I had considered. I played around a little bit with converting type hints into type checks (#6) and I wasn't particularly pleased with what I found, so I gave up on it.

Which seemed necessary because of using unavailable Hypothesis APIs otherwise, which we could just wrap

Yes we want this to just be a skip. Is complex_dtypes not present at all if the version is too low? That should maybe be improved upstream.

[asmeurer]

Different versions can now be selected with set_array_api_strict_flags(api_version=version). However, '2021.12' is not really supported in that if you set the version to 2021.12, it will just return the same thing as 2022.12. There aren't any libraries that really support 2021.12 and not 2022.12, so there's little point to doing so, but if someone really wants it, please open an issue and we can consider it.