[Numpy-discussion] Exported symbols and code reorganization.

[Charles R Harris]

Hi all,

I've started some experiments at breaking up the large multiarraymodule.cand
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?

./random/mtrand.so
000294d4 T _fini
00002da4 T _init
00026ef0 T init_by_array
00023090 T initmtrand
00027020 T loggam
00026db0 T rk_altfill
00028360 T rk_beta
00028fc0 T rk_binomial
00028760 T rk_binomial_btpe
000279f0 T rk_binomial_inversion
000281d0 T rk_chisquare
00026d10 T rk_devfill
00026b40 T rk_double
000273a0 T rk_exponential
00028210 T rk_f
00026ba0 T rk_fill
00028440 T rk_gamma
00026c20 T rk_gauss
00027c70 T rk_geometric
00027bf0 T rk_geometric_inversion
00027180 T rk_geometric_search
00027240 T rk_gumbel
00029430 T rk_hypergeometric
00029090 T rk_hypergeometric_hrua
00027560 T rk_hypergeometric_hyp
00026ae0 T rk_interval
000272a0 T rk_laplace
000271f0 T rk_logistic
00028510 T rk_lognormal
00027470 T rk_logseries
00026ab0 T rk_long
00028480 T rk_negative_binomial
00028270 T rk_noncentral_chisquare
000282f0 T rk_noncentral_f
000284d0 T rk_normal
000273d0 T rk_pareto
00027970 T rk_poisson
00027410 T rk_poisson_mult
00027770 T rk_poisson_ptrs
00027dc0 T rk_power
00026970 T rk_random
00026e10 T rk_randomseed
00027700 T rk_rayleigh
000268f0 T rk_seed
00027f00 T rk_standard_cauchy
00027360 T rk_standard_exponential
00027f40 T rk_standard_gamma
00028120 T rk_standard_t
00027640 T rk_triangular
00026a80 T rk_ulong
00027320 T rk_uniform
00028550 T rk_vonmises
00027e50 T rk_wald
00027e10 T rk_weibull
00027cd0 T rk_zipf

I'm guessing at least some of these should be private. The script that
generates these lists is

for i in $(find . -name "*.so") ; do echo $i && nm $i | grep \ T ;  done ;

executed in the package directory.

That brings up the main question I have about how to break up the C files. I
note that most of the functions in multiarraymodule.c, for instance, are
part of the C-API, and are tagged as belonging to either the MULTIARRAY_API
or the OBJECT_API. Apparently the build system scans for these tags and
extracts the files somewhere. So, what is this API, is it available
somewhere or is the code just copied somewhere convenient. As to breaking up
the files, the scan only covers the code in the two current files, included
code from broken out parts is not seen. This strikes me as a bit of a
kludge, but I am sure there is a reason for it. Anyway, I assume the build
system can be fixed, so that brings up the question of how to break up the
files. The maximal strategy is to make every API functions, with it's helper
functions, a separate file. This adds a *lot* of files, but it is straight
forward and modular. A less drastic approach is to start by breaking
multiarraymodule into four files: the converters, the two apis, and the
module functions. My own preference is for the bunch of files, but I suspect
some will object.

Any comments?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070107/9b0a7505/attachment.html>