> 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
