[Numpy-discussion] slow numpy.clip ?

[Travis Oliphant]

>     My question is then: is there any plan to change this ? If not, is
>     this
>     for some reasons I don't see, or is this just because of lack of
>     manpower ?
>
>
> I raised the possibility of breaking up the files before and Travis 
> was agreeable to the idea. It is still in the back of my mind but I 
> haven't got around to doing anything about it. Maybe we should put 
> together a step by step approach, agree on some file names for the new 
> files, fix the build so it loads in the new stub files in the correct 
> order, and then start moving stuff. My own original desire was to 
> break out the keyword parsers into a separate file but I think Travis 
> had different priorities.

The problem with separate files is (and has always been) the NumPy 
C-API.  I tried to use separate files to some extent (and then use 
#include to make it all one big file).  The C-API is exposed by filling 
in a table of function pointers.  You will notice that when 
arrayobject.h is included for an extension module, all of the C-API is 
defined to pull a particular function pointer out of a table that is 
stored in a Python CObject in the multiarray module extension itself.    
Basically, NumPy is following the standard Python advice (as Numeric and 
Numarray did) about how to expose a C-API, but it's just gotten a bit big.

Solutions to that problem are always welcome.


-Travis