[SciPy-dev] Renaming fftpack to fft, removing backends
Stéfan van der Walt
Fri Oct 31 11:23:00 CDT 2008
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.
> 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
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.
More information about the Scipy-dev