[SciPy-dev] Inclusion of cython code in scipy

[David Cournapeau]

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.

cheers,

David