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