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

David Cournapeau cournape@gmail....
Fri Oct 31 22:15:35 CDT 2008

On Sat, Nov 1, 2008 at 4:25 AM, Robert Kern <robert.kern@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 11:23, Stéfan van der Walt <stefan@sun.ac.za> wrote:
>> 2008/10/28 Robert Kern <robert.kern@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.
> 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
> tidying-up.

If we have this policy, it only makes sense to follow it strictly. API
compatibility is mostly a binary thing: either we allow breakage, or
we don't. To break "a bit" is the same as breaking a lot: it means
people can't rely on it as a stable dependency. That's the part of
your argument that I don't follow, I guess.

Again, I don't mind so much which decision is made, but it would be nice that:
  - the decision is made clearly, so that people are aware of it. At
least Stefan and me were not aware of it. How are we supposed to know
it ?
  - if we go toward API stability, the decision should be enforced. I
don't see how middle ground has any value: it just means people will
break it silently (as it has happened constantly in the past, at least
since I am following it) instead of discussing it.



More information about the Scipy-dev mailing list