[Numpy-discussion] Controlling the way a module is imported

[David Cournapeau]

On Tue, May 27, 2008 at 3:14 PM, Robert Kern <robert.kern at gmail.com> wrote:

>
> I would definitely *not* use environment variables as the sole control
> of FFT backend selection. If I have to restart my IPython session just
> because I forgot to set the right environment variable, I will be very
> unhappy.

Oh yes, I certainly agree it should not be the sole way to control it.
It could, maybe, used to force it, and even then, I am not sure it is
that useful.

>
> For FFTs, I would probably keep the backend functions in a
> module-level list. On import, the package would try to import the
> backends it knows could be bundled in scipy.fftpack and insert them
> into the list. Probably, these would just be the optimized versions;
> the default FFTPACK versions would be kept separate. If an import
> fails, it would be a good idea to format the traceback into a string
> and store it in an accessible location for debugging unintentional
> ImportErrors. Each API function (e.g. rfft()) would check its list for
> an optimized implementation and use it or else fall back to the
> default. Each implementation module (e.g. scipy.fftpack._fftw3, or
> whatever you have named them; I haven't reviewed your code, yet) would
> have an explicit registration function that puts its implementations
> (all or a subset, e.g. _fftw3.register() or _fftw3.register('fft',
> 'rfft')) at the top of the lists

Registration aside, that's more or less what I have done so far.

> handle power-of-two only implementations. This is probably the only
> real special case we have to handle, so we can probably do it
> explicitly instead of coming up with an overly generic solution.

I thought about changing the C Api to return an error code for invalid
input, and writing a python wrapper which calls the default backend
when an error is returned. This way, I can treat any kind of error
without too much burden.

cheers,

David