[SciPy-dev] Renaming fftpack to fft, removing backends

[Robert Kern]

On Tue, Oct 28, 2008 at 03:49, David Cournapeau
<david at ar.media.kyoto-u.ac.jp> wrote:
> Hi,
>
>    There are some things I would like to do for scipy.fftpack during
> the sprint, and I would like to know if anybody would be strongly
> against any one of those:
>
> renaming scipy.fftpack -> scipy.fft
> ===================================
>
> Rationale: fftpack is the name of an implementation (fftpack being the
> name of the Fortran library we use when no other fft library is
> available), and does not fit the convention of any other scipy top
> subpackage.
>
> How: For 0.7, we could rename it while keeping scipy.fftpack as an empty
> placeholder (like scipy.linsolve), and deprecating scipy.fftpack.

This needs to be handled carefully. scipy.fft() already exists. It
also breaks long-standing code (after the deprecation) for no reason
that I find compelling. The name has been there for many years. The
only complaint about it that I have ever seen on the lists was that
people thought that only FFTPACK was supported. Given the following
proposal, that reason goes away. Furthermore, I sometimes have trouble
remembering whether the 'fft' symbol I have imported was numpy.fft or
numpy.fft.fft. This change compounds that confusion.

Overall, I don't think that mere renaming is ever a good reason to
break code. It just feels gratuitous. Yes, there might be some benefit
to having clearer names than what we have lived with so far (although
in this case, I think this is dubious for the reasons given above),
but there is always an enormous downside to breaking code. The
deprecation policy does nothing to reduce that downside. It was never
intended to reduce that downside. Right now, I'm almost sorry for
having introduced it because it appears to be giving the impression
that it is okay to make these kinds of changes.

-1

> Removing all backends but fftpack
> =================================
>
> Rationale: we have 5 backends (fftpack, djbfft, fftw2 and 3, mkl), and
> none of them is complete. I would much prefer focus on one (fftpack),
> make it complete (for example supporting float32 type), than having 5
> half implemented ones. Although, more backends mean more reliability
> problems for installation, distribution, support, etc...

+1

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco