<br><br><div><span class="gmail_quote">On 1/7/07, <b class="gmail_sendername">Robert Kern</b> <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Charles R Harris wrote:</blockquote><div><br><snip> <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">No, but as with mtrand, most of those arise from the fact that these functions
<br>are implemented in files other than the C file that contains the Python module<br>code. In order for them to be called from the Python module code, they need to<br>be exported, IIRMCC (If I Remember My C Correctly). This appears to be true of
<br>essentially every other extension module in my site-packages, so I don't think<br>it's going to be much of a problem.</blockquote><div><br>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.
<br><br>Chuck<br></div><br></div><br>