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

Robert Kern robert.kern@gmail....
Fri Oct 31 22:50:55 CDT 2008

On Fri, Oct 31, 2008 at 22:15, David Cournapeau <cournape@gmail.com> wrote:
> 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.

It's not true that it's entirely binary. Some changes are more severe
than others, and some changes have more benefits than others. Not all
parts of a library are widely used. Specifications of behavior are
sometimes vague or nonexistent, so changes to them might be
acceptable. APIs are sometimes buggy (not just their implementation)
and need to be fixed. Absolute, strict compatibility is impossible to
achieve while still  improving the software. But sensible compromises
can be made.

For example, Python itself is a pretty good project for maintaining
backwards compatibility. But behavior changes do happen, and
deeply-diving codebases like Twisted do break on just about every new
2.x release. Because the changes are usually beneficial to a wide
audience while the breakage is limited to small parts of libraries
that are depending on mostly unspecified behavior, these changes are
usually considered acceptable. To avoid this level of breakage would
mean stopping developing Python altogether (this is not my opinion,
but Martin van Löwis's, and he knows more about it than I).

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

I don't see how it follows that taking my "middle ground" stance means
that people won't discuss possibly-code-breaking changes they are
making. It seems to me that it would encourage more discussion because
the tradeoffs need to be justified and agreed upon. Whereas taking the
"any code-breaking changes are acceptable before 1.0" seems like it
might let these changes get lost in the shuffle because no
justification needs to happen.

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

More information about the Scipy-dev mailing list