David Cournapeau wrote:
> 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.
>>>>>>>> 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