I've been implementing a native C++ code with all of the functionality of the Python Uncertanties package (http://packages.python.org/uncertainties/). Automatic error propagation (and differentiation) is extremely useful, but native speed is needed to use in things like function fitting. I have created the type and successfully bound it to numpy (though still missing a lot of UFuncs), but I have a hangup in that I have no clean way to call a destructor on the numeric type (it is variable length via a held pointer). I could keep it in the array as a python object and get xdecref to do it, but I would much rather A: not have the overhead and B: I really want to keep the GIL free. All of the other PyArray_ArrFuncs which manage the type appear to allow pairing a destructor when memory is overwritten, and constructors are all well supported (like copyswap, setitem and fillwithscalar). I'd like to propose adding a flag for PyArray_Descr.flags NPY_ITEM_USES_DESTRUCTOR and a function PyArray_ArrFuncs.destructor with void destruct(void *data, npy_intp dstride, npy_intp len, void *arr) where data points into the data array to be affected, dstride is the data stride, len is number of affected elements, and arr is the array object containing data. It may be possible to change the call structure of another element when this flag is set (to preserve ABI compatibility for existing types). This flag would by inherited when NPY_FROM_FIELDS is set. Subclassing PyArray_Descr may also allow preservation of the API. The current implementation of NPY_ITEM_REFCOUNT could potentially use this more-general destructor implementation to call xdecref. I could potentialy implement this in a branch, but I'd like to know what other's think of it as well as how best to do it to minimize its effect on the rest of the code and external libraries. For anyone interested in the details of this uncertainties code - My error propagation class are a C++ numeric type, which carry around a list of partial derivatives between new values and all of the values used to compute them. This list is a C++ vector which needs its destructor called. My bindings are hand-written, but should provide a good template for binding to other C++ numeric types. For instance, it would not be hard to extend them also add numpy support for arbitrary precision math types, which would also need their C++ destructors called.