Following on from some of the discussion surrounding my backend proposal and the discussion on gh-10175<https://github.com/scipy/scipy/issues/10175>; I've been working on adding a new scipy.fft submodule. This is now working, tested, documented and ready for review in gh-10238<https://github.com/scipy/scipy/pull/10238>. The new submodule is almost a drop-in replacement for numpy.fft and scipy.fftpack, with a few exceptions: * Does not include NumPy's Hermitian transforms (hfft, ihfft) (but would be simple to add) * Uses numpy's conventions for rfft (complex array) instead of fftpack's (complex values packed into a real array) * Convolutions and pseudo-differential operators from fftpack are not included The new submodule adds pocketfft to implement the normal FFTs (not yet DCT and DST) which adds several new features beyond scipy.fftpack: * long double transforms * multi-dimensional real FFTs (rfftn) * Orthonormal transforms (norm='ortho' argument) * Bluestein's algorithm to avoid the worst case O(n^2) complexity of FFTPACK A few implementation details worth noting: * Unlike NumPy's version of pocketfft, this is C++ and uses templates to supporting the different floating point types * pocketfft also uses pybind11 which both adds a new build-time dependency and requires C++11. I believe this is the first use of C++11 in SciPy. * pocketfft has optional support for multithreading using OpenMP but this is currently disabled (and not compiled in at all). And finally, there is the rather awkward issue that scipy.fft already exists and is an alias for the numpy.fft.fft function. Currently I've had to add a workaround to allow the module scipy.fft to be callable, as discussed in gh-10253<https://github.com/scipy/scipy/issues/10253>. This is only relevant to code that imports scipy.fft so I don't expect it to be used often, if at all. Hopefully this is a temporary solution and the NumPy functions can be removed from the scipy namespace in some future release, or at the very least the FFT functions can be removed. Peter