[Numpy-discussion] slow numpy.clip ?

[David Cournapeau]

On 12/22/06, Robert Kern <robert.kern at gmail.com> wrote:
> Charles R Harris wrote:
>
> > I've been thinking about that a bit. One solution is to have a small
> > python program that takes all the pieces and writes one big build file,
> > I think something like that happens now. Another might be to use
> > includes in a base file; there is nothing sacred about not including .c
> > files or not putting code in .h files, it is just a convention, we could
> > even chose another extension.  I also wonder if we couldn't just link in
> > object files. The table of function pointers just needs some addresses
> > and, while the python convention of hiding all the function names by
> > using static functions is nice, it is probably not required. Maybe we
> > could use ctypes in some way?
> >
> > I am not pushing any of these alternatives at the moment, just putting
> > them down. Maybe there are others?
>
> None that I want to think about. #including separate .c files, leaving the
> extension alone, is best, IMO.
>
>
I've studied a bit how exposing C api from python extensions work at
the python.org website. My understanding is that the problem when
splitting into different files is that the C standard has no class
storage equivalent to a "shared static", eg using a function in
several C files of the same shared library, without the function being
exposed in the shared library.

One elegant solution for this is non portable, unfortunately: recent
gcc version has this functionality called new C++ visibility support,
which also works for C source files.

http://gcc.gnu.org/wiki/Visibility

This file explains the different ways of limiting symbols in dso available

http://people.redhat.com/drepper/dsohowto.pdf

Having several include of C files is the easiest way, and I guess this
would be the safest way to start splitting source files. A better way
can always be used after anyway, I guess.

The question would be then: how do people think one should split the
files ? By topics (eg one file for arrays destruction/construction,
one file for elementary operations, one file for the C api, etc...) ?

I am willing to spend some time on this, if this is considered useful,

cheers,

David