Charles R Harris wrote: > Hi all, > > I've started some experiments at breaking up the large > multiarraymodule.c and arrayobject.c files. As part of this I also > looked at what symbols are currently exported by the *.so libraries. > Most are just the usual three python symbols, but multiarray, mtrand, > and fftpack_lite have extras. > > ./core/multiarray.so > 000530b4 T _fini > 0004d450 T _flat_copyinto > 00005f58 T _init > 000107e0 T count_new_axes_0d > 0002c160 T initmultiarray > > I'm guessing the extras are unintended and should be made static. > > ./fft/fftpack_lite.so > 00008284 T _fini > 000008a4 T _init > 00003570 T cfftb > 00003530 T cfftf > 00003800 T cffti > 00001070 T fftpack_cfftb > 00001220 T fftpack_cfftf > 00000df0 T fftpack_rfftb > 000013d0 T fftpack_rfftf > 00000c30 T initfftpack_lite > 00005e20 T rfftb > 000039b0 T rfftb1 > 00006f30 T rfftf > 00003680 T rffti > > Is there a good reason to make all those global? Is the library intended > to be used as more than a module?
No, but as with mtrand, most of those arise from the fact that these functions are implemented in files other than the C file that contains the Python module code. In order for them to be called from the Python module code, they need to be exported, IIRMCC (If I Remember My C Correctly). This appears to be true of essentially every other extension module in my site-packages, so I don't think it's going to be much of a problem. -- 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
