ENH: Add 2022.12 support to numpy.array_api

[asmeurer]

Proposed new feature or change:

This is a tracking issue for adding v2022.12 support to numpy.array_api. If possible this should happen before the 1.25 release (I hope I'm not too late for that), because that will make things much easier for people adopting the array API.

The work should be straightforward. It mainly consists of making sure functions accept complex dtypes, although there are also a few new functions that need to be added (like real and imag).

[charris]

It's getting late for the 1.25.0 release, I'd like to get it out before the end of the month. However, as long as it only affects array_api I feel pretty free to backport it at any time, that is a work in progress and having it up to date for people working with it isn't a problem. Changes to the mainline api will need to wait.

[asmeurer]

Actually, there's a bit of an open question here. Do we want to support the api_version='2021.12' argument to __array_namespace__? That is, make it somehow return a version of the namespace corresponding to NumPy 1.24? I'm not sure if there's a simple way to do this. My initial thinking is we shouldn't attempt this, at least for now. If people want to test against an older version of the spec they can just use an older numpy.

[asmeurer]

This is only numpy.array_api. I'll work to get something ASAP (is there a branch I should be working against rather than main?)

[charris]

is there a branch I should be working against rather than main

No, just make it against main. After it goes in I can just copy the files into a PR against 1.25 at any time.

[asmeurer]

OK, I've implemented everything at #23881. There's just one open question about whether we want to try to add the fft extension, but other than that, everything is ready. We should also try to include #23789 in 1.25 too.

[seberg]

NumPy's FFT is only 64bit, there was potentially something else with the way the custom length is handled (I don't quite remember).

I don't mind just pushing this through, the namespace has a warning and I wouldn't even worry about updates in a bug-fix release.

After that, maybe we should discuss removing the namespace, though? The main reason for it to be here was that the NEP 47 draft hoped for it to be useful beyond testing, I think (and e.g. review also, yes). As it has not proven to be used for more than testing right now, there is no user-facing reason for it to remain, I think.
Moving it out, would remove the burden of coordinating with NumPy releases.

We don't need to do it on a schedule, but to me it seems like this should happen eventually, I simply see no great reason for the opposite.

[asmeurer]

NumPy's FFT is only 64bit, there was potentially something else with the way the custom length is handled (I don't quite remember).

OK, so that sounds like there is actually going to be some work involved then, so I'm not going to do it here. I don't want to stall this, and I would need to implement test suite support to feel confident about it.

I wonder if I should add a simple fft.py with a NotImplementedError or something for now.

We don't need to do it on a schedule, but to me it seems like this should happen eventually, I simply see no great reason for the opposite.

I'm also open to that, although wouldn't it make the most sense to do it in NumPy 2.0 if we are going to do it?

[asmeurer]

Opened #23892 to track fft support.