[SciPy-dev] Cython / python policy

[David Cournapeau]

On Sat, Mar 7, 2009 at 6:30 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi David, and team,
>
> David, I've quoted you here on your response to an offer to submit
> some code to your scikit, but as a jumping off point for further
> discussion.
>
>> There are only two big requirements:
>>  - I do want a pure python implementation for everything (with
>> optional C/Cython).
>
> I was just thinking of doing some Cython.
>
> Do we think that, in general, scipy code should have both C(ython)
> _and_ python implementations of the same thing, with different names,
> as for Anne's spatial package?

I think we should have as much python code as possible. We have too
much C/C++/Fortran code already, and this is order of magnitude harder
to maintain than python. As long as the original writer is there, it
is ok, but when he is not available anymore, it can become a problem.
When you have semi working code in C (or worse fortran or C++),
without documentation, it is almost guaranteed to become
unmaintainable short of rewriting.

Even cython has problems - only for it cannot support complex number
or other features of numpy as well as python code. Having a pure
python code is even more useful than test in my experience.

>
> Or, in different namespaces (scipy.mypackage.c.func,
> scipy.mypackage.python.func sort of thing)

I have tried with different namespace and package names: it does not
work very well. I agree with Sturla that we should follow the python
way of doing things if possible.

But there is still the problem of python implementation which does
more than the C implementation.I have this case in my scikits, because
cython does not have native complex number handling yet, so my routine
for Levinson Durbin (a well known method for inversion of toeplitz
matrix) works for real and complex number in python, but only for real
in cython (the cython version is order of magnitude faster though -
the code cannot be vectorized efficiently).

cheers,

David