[Numpy-discussion] slow numpy.clip ?

[Travis Oliphant]

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