[Numpy-discussion] Exported symbols and code reorganization.
Charles R Harris
charlesr.harris at gmail.com
Tue Jan 9 09:08:11 CST 2007
On 1/9/07, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
> Charles R Harris wrote:
> > On 1/7/07, *Robert Kern* <robert.kern at gmail.com
> > <mailto:robert.kern at gmail.com>> wrote:
> > Charles R Harris wrote:
> > <snip>
> > 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.
> > I don't think unnecessary public symbols are much of a problem,
> > either, but it bears on the question of breaking up the core numpy
> > files. The parts could be treated in the same way, i.e., compiled
> > separately and linked, or they could be treated as you suggested
> > previously, declared static and the code included into one base file.
> > I suspect the inclusion route is a bit easier from a portability
> > standpoint, long link lists can be a problem and the making of
> > libraries is platform dependent.
> Bit late at joining the discussion... I started the same thing,
> splitting up those files.
> As Travis reminded me in a previous discussion, most symbols in numpy
> extensions are private (eg static functions) because that's the way
> python extension works:
I think we can do what the multiarray module does, provide a table of
function pointers in the _XXX_API module attribute. That way the random and
fft functions would be available to c extension modules for those who wanted
them while also being kept out of the module namespace.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion