David Cournapeau wrote: > On 12/22/06, Robert Kern <[EMAIL PROTECTED]> 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. >> >> >> > > 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 think it's useful but don't have time to think very much about it. I suspect anything that's semi-coherent that results in smaller files will be beneficial for editing purposes. The only real opinion I have at this point is that I'd like to see multiarraymodule.c contain little more than include statements (of headers and other .c files) and comments. -Travis _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
