[SciPy-dev] Cython / python policy
Fri Mar 6 15:48:54 CST 2009
2009/3/6 Matthew Brett <firstname.lastname@example.org>:
> 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
>> 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?
Just let me chime in here to point out two things:
* The python implementation predates the cython implementation, and in
fact the cython implementation began as a conversion of the python
implementation. I'm not necessarily advocating this, just describing
how I did it.
* The python implementation provides additional functionality at the
expense of speed. In particular, if people want to write additional
algorithms, particularly those that involve annotating the kd-tree,
the python implementation makes this much easier that the cython
I don't think it's worth providing a python implementation solely for
those who can't compile the cython one; after all, cython modules are
distributed as C, and if a user can't compile C they much of scipy
breaks, But for certain things a python implementation allows more
flexibility: that's why, for example, for years python supported both
pickle and cPickle.
> Or, in different namespaces (scipy.mypackage.c.func,
> scipy.mypackage.python.func sort of thing)
> Or, switched by a decorator (that depends on a conditional import), like this:
> def func(a, b):
> return a+b # or something
> (an idea from http://www.lfd.uci.edu/~gohlke/code/transformations.py.html).
> To me, all these seem to add maintenance overhead without much gain.
> We don't do that for C++ wrapping, after all...
> Scipy-dev mailing list
More information about the Scipy-dev