[SciPy-dev] Inclusion of cython code in scipy
Fri Apr 25 07:19:47 CDT 2008
Prabhu Ramachandran wrote:
> Brian Granger wrote:
>>> > C++ STL containers are truly great for things like this. I would
>>> > write a simple c++ header file that defines the Particle class, create
>>> > an std::vector<Particle> to hold them and wrap the whole thing into
>>> > Cython. I have already done stuff like this (templated c++ with STL)
>>> > with cython and it works great. Furthermore, you end up with an
>>> > actual C/Python extension type that 1) is super fast 2) has its own C
>>> > api that can be called from other C extensions.
> For some strange reason I still haven't gotten this email but Brian,
> that is the point I was making, STL has all the needed container classes
> for this and this is precisely what I use. I just use SWIG to wrap this
> C++ code and it works great. Much of the STL is already wrapped via
> SWIG and with numpy.i it interfaces quite well with numpy, in addition
> you can inject doxygen generated documentation almost automatically so
> your generated wrapper code is fully documented.
- there is almost no C++ code in scipy, and none in numpy
- there is already some pyrex code in numpy (numpy.random)
- there is no STL use, as far as I know at least, in numpy or scipy.
So I don't see how a discussion about C++ and stl is relevant for
numpy/scipy. The original email was about including cython code: if the
choice is between no code and cython code, I know which side I am on.
Swig has problems too, BTW. For example, when I was working on
scipy.cluster last year, I could not regenerate the source file because
of SWIG version mismatches, and at the end, I just found easier to
rewrite the extension in pure C (it was really small).
I am sure that for you, swig + C++ is better. But for other, it isn't.
If swig is allowed, I really don't see why cython would not be.
> I've also explored using D and PyD and it makes for a fantastic
> combination. D seems to be (gdc) about 1.7 times slower than C++ but is
> really nice to work with. PyD's support for numpy is lacking but could
> be fixed.
> The point is (and what I understand of what Nathan was saying), pyrex
> and cython let you wrap the code to an extent but do not provide the
> underlying solution. People were arging that Cython may be used in
> place of C, and I think our point is that it isn't there yet and for
> people used to C or C++ it is much easier to just use those instead.
I consider myself to be a decent C programmer, and I don't like swig. It
just depends on people and their problems.
More information about the Scipy-dev