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

Robert Kern robert.kern@gmail....
Fri Oct 31 15:40:06 CDT 2008

On Fri, Oct 31, 2008 at 14:50, Jarrod Millman <millman@berkeley.edu> wrote:
> On Fri, Oct 31, 2008 at 12:25 PM, Robert Kern <robert.kern@gmail.com> wrote:
>>> 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.
> It may not have been the 'official' policy, but I think that it is
> what a fair number of people including (it seems) Stefan, David, and
> myself believed was the policy.  I think a large number of people view
> the 1.0 release of any project as a dividing line (arbitrary or not).
> Furthermore, the development status of scipy has been advertised as
> "Beta" for as long as I can remember:
> http://pypi.python.org/pypi/scipy
> Most importantly, scipy has the feel of an unfinished project.
> Documentation, naming, calling conventions, and many other aspects of
> it highlight its nature as a work in progress.  We need to come to
> some agreement, I think, as how to proceed with the API changes that
> we need to make and what the official policy for moving toward a 1.0
> release should be.  Maybe we need to change the release numbers to
> include some indication that the software is still rapidly evolving.
> Personally, I am fine with using the pre-1.0 numbering to signify
> this; but I am open to other ideas.

If you want to do that, fine. But make it public and official soon.
And when we get to 1.0, we need to keep our promises.

> At the very least, we need to
> decide whether we believe that we need to make significant changes to
> the API and how to best convey that this is the case to our users.
> Clearly, none of us want to ignore the needs of our users.  But we
> need to balance the needs of current users to have relatively stable
> dependencies with the needs of future users to have a highly polished,
> cleanly designed, and easy to use packages for scientific computing in
> Python.
> Without thinking to hard, I can quickly think of a number of changes
> that I would like to see prior to what I would consider a "1.0"
> release.  For example, these top-level packages are good candidates, I
> believe, for renaming, removing, or reintroducing:
>  - scipy.fftpack
>  - scipy.linsolv
>  - scipy.stsci
>  - scipy.misc
>  - scipy.lib
>  - scipy.ga
> There are also a number of other API cleanups that I would like to see
> before a 1.0 release.
> Thoughts? Ideas?

I am less opposed to substantive restructurings. They usually provide
a concrete, technical benefit to counter the concrete, technical costs
of having to change code. Simple renamings don't. Their benefits are
typically hypothetical or anecdotal. In the case of fftpack->fft, I
have given reasons why the new name would have problems, too (when
possible, never have a package/module named the same thing as a
function or class it provides), so I think any benefit from renaming
ultimately comes out as a wash. That just leaves us with the
substantial costs.

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