I was able to build and test this on python2.4 on solaris and python 2.6 on linux. Compilation and spot check of several examples looked good. Unfortunately a lot of tests are failing for me on both platforms because of font issues, but this is the same as in master so I don't think your changes are implicated.

I am still hesistant about this one. What are the implications of switching to PyCapsule? There must be a fundamental difference between PyCObject and PyCapsule, right? Are we going to have issues with extension developers (I am thinking along the lines of ABI compatibility and such). Also, will this cause confusion with binary builds of matplotlib? I take it that we will need a Windows installer for py2.5-6 and a separate one for py2.7? Maybe the same for Macs?

We've always done python version dependent builds for windows and os x.

@WeatherGod:
PyCObject and PyCapsule are basically ways to wrap opaque C-pointers and send them to and from Python. PyCObject has a number of shortcomings, mainly 1) no standard way to specify the type of the pointer, and therefore doesn't encourage good type-checking (though it doesn't prevent it), 2) no convenient way to call a destructor when the references drop to 0, 3) its members are not private.

You can see a rationale for the PyCapsule API here:

http://bugs.python.org/issue5630

The features of the new design are very welcome but not particularly necessary for PyCXX, since PyCXX already handles the type safety and destructor features that PyCapsule addresses. So we really only need to use the very basic functionality of PyCapsule (namely PyCapsule_New and PyCapsule_GetPointer). In some ways it could be said that the new features of PyCapsule are really only helpful for those writing new code that wraps an existing C library -- PyCXX is a different sort of animal that has to manage many of its own details.

There are no implications for extension authors. Extension authors are still free to use whatever wrapper mechanism they wish, and matplotlib (unlike Numpy, for example) does not expose a C API.

ABI compatibility across different non-bugfix releases of Python has never been guaranteed by Python's design. We will need to produce binaries for multiple versions of Python anyway.

As a side note, it should be noted that numpy git master as of now still uses PyCObject on Python 2.7, so unless that is addressed over there (I have no idea what if any plans the numpy folks have in that regard) there will still be PendingDeprecationWarnings emitted from numpy.

Ok, that makes me feel much more comfortable with merging this in. I just wanted to do some sanity checks here.