I vote for using the raw Python/C API. I've written a couple of PyCXX
extensions and whilst it is mostly convenient, PyCXX doesn't support the
use of numpy arrays so for them you have to use the Python/C API. This
means dealing with the reference counting yourself for numpy arrays;
extending this to do the reference counting for all python objects is not
onerous. Dealing with object lifetimes is bread-and-butter work for C/C++
developers.
I have never used Cython, but to me the code looks like an inelegant
combination of Python, C/C++ and some Cython-specific stuff. I can see the
advantage of this approach for small sections of code, but I have strong
reservations about using it for complicated modules that have extensive use
of templated code and/or Standard Template Library collections (mpl has
examples of both of these).
I agree that Cython opens us up to a larger body of contributors, but I
don't think that this is necessarily a good thing. I think this really
means opens us up to a larger body of Python/Cython contributors, and is a
view expressed from the Python side of the fence and has the wrong
emphasis. I am primarily a C++ developer is a sea of Python developers,
and rather than encourage other Python contributors to dip their toes into
C/C++ via Cython I think we should be encouraging C/C++ contributors to do
what they do best. We only need a few C/C++ developers if we allow them to
use their skills in their preferred way, and they are used to interfacing
to legacy APIs and dealing with object lifetimes.
OK, cards on the table. If we wanted to switch all of our PyCXX modules to
use the raw Python/C API, I would happily take on some of the burden for
making the changes and ongoing maintenance of such modules. Particularly
if, in return, I get some help with my sometimes substandard Python! If we
go down the Cython route I couldn't make this offer; would our many Cython
advocates take on the responsibility of changing and maintaining my C++
code in this scenario?
Ian Thomas
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
