> I think that numpy.fft should be left there in its current state (although perhaps as deprecated). Now scipy.fft should have a good generic algorithm as default, and easily allow for different implementations to be accessed through the same interface.I also agree with the above. But I want to add that in this case it would be wise to include some (sophisticated) testing suite to ensure that all possible libraries implement the DFT with high accuracy.

numpy's fftpack (or scipy's) has the advantage that it is old and well tested. FFTW also provides extensive benchmarks of speed and accuracy. Other libraries do not. Most users just want an fft function that works and not bother with details like numerical accuracy. When I encountered such an issue (https://github.com/hgomersall/pyFFTW/issues/51) it took me really a long time to track it down to the fft function.

One remark to FFTS: does it implement double precision yet? The corresponding issue (https://github.com/anthonix/ffts/issues/24) seems to be still open but I did not look into it. If it does not it is not suited as a fftpack replacement (I hope I did not overlook some comment about that in the thread).

Cheers
Nils

PS: although I am a long time user of numpy, I am fairly new to the list. So hello!