> see inline comments:
>
> On Fri, Nov 5, 2010 at 2:02 PM, Maël Primet <mael.primet@gmail.com> wrote:
>
>> Well,
>>
>> perhaps we should talk about this a little more, because there are many
>> aspects:
>> - of course, Cython has a more clean feeling
>> - however, it is still not as efficient as C (for some of the code I
>> published, I tried the Cython version first, then switched to C when I saw
>> that it was too slow)
>>
>
> I suspect this has more to do with how you've written the Cython versus the
> speed of Cython vs C. Cython is *very* fast when properly used.
>
>
>>
> - some older user of the library, less able with python, might still want to
>> develop C code and bind it if there is an easy way to do it
>>
>
> Since our data structure is a numpy array, manipulating that pointer in C
> would take an awful lot of knowledge about NumPy internals. Raising an
> exception even moreso. It would be less effort for said person to just learn
> Cython.
>
>
>> - it is interesting to have some simple C core code, like a function that
>> takes arrays as double * and (w, h) integers, because it enables easy reuse
>> of the core of the algorithm for some other projects (without having to
>> include the whole library) if someone only wants to extract one or two
>> algorithm (this might be interesting when we develop research code and some
>> private company want to use the algorithm )
>>
>>
> There is nothing stopping you from doing that in your own personal library.
> But seeing as how we creating a library for image processing in Python, I
> think we should use the best available tools for Python, thus making things
> most accessible and maintainable to our target audience.