On 12/20/06, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> 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.
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? Chuck
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
