[SciPy-dev] Cython / python policy

Hoyt Koepke hoytak@cs.ubc...
Fri Mar 6 16:08:44 CST 2009


While I'm not a regular scipy contributer, in my research I use scipy
a lot and use cython a lot.  From personal experience, I have found
that the *small* bit of extra work involved in cythonizing your code
almost always pays off unless speed really doesn't matter.
Additionally, cython tries hard to generate maximally portable C code,
and has good mechanisms for exception handling, etc. that are very
tedious to implement in straight C code.  So including more cython
code, and even cythonizing some existing code, gets a +1 from me.

Along with what Anne said, I think that ease of subclassing is the
only real argument for having both python and cython implementations
of the same thing floating around (besides, perhaps, backwards
compatibility if that's an issue).  It seems that sticking to the
"justified by use cases" reasoning that python itself employs here is
appropriate -- i.e. Is there a use case common enough, and where
subclassing would significantly be more difficult than other ways
around it, to justify the added complexity of two solutions?

Note that cython actually improves this subclassing issue
significantly over straight c or fortran extensions.  If there is a
policy that all cython extension type code must have an accompanying
.pxd definition file, one can simply subclass that type in cython
without much difficulty.

Just a few thoughts...


+ Hoyt Koepke
+ University of Washington Department of Statistics
+ http://www.stat.washington.edu/~hoytak/
+ hoytak@gmail.com

More information about the Scipy-dev mailing list