This should be ready for review. It's possible some of the dtype restrictions will change in the spec (see the discussion at data-apis/array-api#720 (comment)), but if that happens we can update this with another PR.

Will need a release note.

I think the tests are still skipped:

When trying this in JAX, I found that array_api_tests/test_fft.py has a number of dtype expectations that don't align with the dtypes of jax.numpy.fft, which was designed to follow numpy.fft. So I'm interested to see if you run into the same isssue.

I didn't realize that the array api tests are run on the numpy CI now. I've been running them manually. The dtype stuff is addressed here. The fft functions in numpy all upcast 32-bit inputs, which the spec says they shouldn't. This is addressed here by re-downcasting, but I also plan to fix this in numpy.fft itself (my understanding is that this should be straightforward once #25536 is merged). There are also some issues in the test suite itself so we may need to get those addressed before we remove the skips.

I'll test this in SciPy with a NumPy nightly soon

Note: we need to address a few issues upstream in the standard and the array-api-tests before this should be merged

Does this mean that array-api-tests is up to scratch for fft now and we can remove the skip in CI here?

Does this mean that array-api-tests is up to scratch for fft now and we can remove the skip in CI here?

No, the test suite still needs to be updated for data-apis/array-api#720, and also some of the shape tests are wrong. (cc @honno)

At any rate, as soon as #25370 is merged the plan is to move numpy.array_api to another repo, and (presumably) delete it from this one, so I wouldn't worry too much right now about the array api CI skips for numpy.array_api. As for the main namespace fft, it is still incorrect in upcasting 32-bit inputs. I plan to fix this, but I need #25536 first, as I understand it.