Yes, an excellent summary and neatly bringing us back to the crux of the matter.

For completeness I should say that I wouldn't use SWIG.  I used it about 5 years ago to wrap some C++ for Python and other languages.  Initially it was very useful, but eventually the default mapping between C++ and Python types and the default handling of object lifetimes weren't quite what I wanted and I found myself writing a lot of extra configuration code to coax it back in line.  In the end I went back to the Python/C API.  Perhaps its aim of targetting many different languages means it isn't suited for our language of interest.  It doesn't support Numpy arrays anyway.

I would like to be able to recommend Boost.Python, but I have never used it.  I have used some Boost modules and found all to be well-designed and actively maintained.  However, it currently doesn't support Numpy arrays (although it is an active area of work) and it appears that there are difficulties building it with anything other than the default build tool BJam leading to concerns over portability.

Although my preference, in the absence of PyCXX, for wrapping our larger C/C++ modules is to use the Python/C API rather than Cython, I have been persuaded that there is a place for Cython in matplotlib.  The ability to improve the performance of small sections of Python code in a simple and localised manner seems very useful, and would be a good starting point for speeding up areas of code that a number of users are frustrated by.  Given the number of people who would like to see it used in matplotlib, I think it is inevitable that we eventually will.

I hadn't really considered the option of adding Numpy arrays to PyCXX.  I've taken a quick look at the existing code and whilst I don't think it is a trivial task it looks well worth investigating - the existing code is well organised and quite well documented.  If two or more of us were prepared to make the Numpy additions to PyCXX and provide ongoing maintenance, we would address the deficiencies of the current solution and remove the single-person bottleneck.  But I am not sure where this leaves us as I a now advocating use of Cython to some extent and hence we would have two wrapping tools.  Should we reject Cython + improved PyCXX on these grounds and revert to Cython + Python/C API?

Ian