[Numpy-discussion] Exported symbols and code reorganization.

[Robert Kern]

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