[SciPy-dev] Renaming fftpack to fft, removing backends
Fri Oct 31 14:25:10 CDT 2008
On Fri, Oct 31, 2008 at 11:23, Stéfan van der Walt <email@example.com> wrote:
> 2008/10/28 Robert Kern <firstname.lastname@example.org>:
>>> 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.
I agree that it doesn't belong there. Personally, I would like to
remove everything from the top-level. However, I don't particularly
agree that we have no constraints on reorganizing scipy. With numpy we
made a clear statement that the API was going to change up until 1.0,
at which point we made some promises of stability. Consequently, we
felt comfortable changing the API before 1.0 without concern for
breaking people's code. With scipy, that's not the case. 1.0 is not
and has never been the arbitrary dividing line between instability and
stability for this project. scipy is installed, people are using it,
and we have an obligation not to break their code for minor
>> 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.
There's a difference between "structure" and "naming".
>> 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
> 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.
That has never been scipy's policy.
"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
More information about the Scipy-dev