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

[Stéfan van der Walt]

2008/10/28 Robert Kern <robert.kern at gmail.com>:
>> 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

scipy.fft() just contributes to SciPy root pollution.  Unlike with
NumPy, we still have the opportunity to organise SciPy well, and I
don't think fft() belongs at the top level.

> also breaks long-standing code (after the deprecation) for no reason
> that I find compelling. The name has been there for many years. The

Improving the package structure is a good reason, in my opinion.

> 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.

Maybe, but I still find it better than having

numpy.almostanything -> scipy.almostanything

but

numpy.fft -> package while scipy.fft -> function

It seems more natural to have

module.fft -> package

module.fft.fft -> function

> 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.

We're not at 1.0 yet, so we need to allow for some leeway in adjusting
the package to have the best possible layout.  The sooner we sort
these things out, the sooner we'll have an API worth freezing.

Regards
Stéfan