[SciPy-dev] fftpack: building all backends and setting them at runtime (was dropping djbfft)

David Cournapeau david@ar.media.kyoto-u.ac...
Fri May 16 08:45:24 CDT 2008

Pearu Peterson wrote:
> No, the suggestion was to split the pyf file into 3 pieces:
> part 0, the call* calles, part 1.
> Now that I look at it, it seems that also call* parts are
> identical for all backends except the module name part. This
> should make also the split of files unnecessary.
> I'll take a look at the branch and see if I can figure something
> easier out..

Great, thanks for looking at this.

> Why? Isn't C functions static and so there should be no conflicts
> provided that all backends have their own extension modules.
> May be I am overlooking something..

The functions exposed by f2py cannot be static, and contrary to what was 
the case before, it is possible to have several backends loaded at the 
same time at the python <-> C layer (this was not a problem before since 
the several backends were only used inside C, and as such, several 
backends were never present in the python <-> C layer).

Actually, it is one of the nice benefit of the current approach "for 
free": you don't have to rebuild fftpack to use a different backend. 
Typically, I can now test all backends just by changing one line in the 
fftpack module, and once we decide on the best approach for 
registration, we will be able to do it purely at runtime in python.

> That's easy, one should use `fortranname` statement in pyd files.
> Search fortranname in f2py users manual.

Thanks, I will modify this part, then, instead of doing the renaming in 



More information about the Scipy-dev mailing list