On 1/9/07, David Cournapeau <[EMAIL PROTECTED]> wrote:
Charles R Harris wrote: > > > On 1/7/07, *Robert Kern* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
