[SciPy-dev] Renaming fftpack to fft, removing backends
David Cournapeau
david@ar.media.kyoto-u.ac...
Wed Oct 29 01:55:43 CDT 2008
Robert Kern wrote:
>
> This needs to be handled carefully. scipy.fft() already exists.
This scipy.fft is numpy one, right ? I thought those numpy import were
deprecated. If not, then it becomes much less clear to me to do the
change as suggested, indeed.
> It
> also breaks long-standing code (after the deprecation) for no reason
> that I find compelling. The name has been there for many years. The
> only complaint about it that I have ever seen on the lists was that
> people thought that only FFTPACK was supported.
This is only anecdotal, but I thought fftpack was confusing when I
started using scipy. I did not even know what fftpack was.
> Given the following
> 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.
Hm, I have the same problem, and that's why my goal for the renaming was
to be the same as numpy: numpy.fft and scipy.fft both are modules, and
numpy.fft.fft and scipy.fft.fft are fft functions. So this intended,
although I can see why this can be seen as making it worse instead of
better, specially with scipy.fft already existing (which I did not know
existed, or at least forgot about).
>
> 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.
I don't agree that deprecation policy does nothing to alleviate the
breaking code problem: if something breaks, it is much better to know it
with a deprecation warning than not knowing it and getting silent
breakages. I wish there were a deprecation warning when axis default
changed in numpy two years ago, for example. I understand the point that
introducing policies somewhat makes it easier to break API, though.
I don't want to start this discussion here, because that's a bit
off-topic, but I think we need to discuss those policies (for scipy - I
agree we should be really conservative for numpy) to reach an agreement
at some point.
cheers,
David
More information about the Scipy-dev
mailing list