[Numpy-discussion] Enhanced array destruction needed for C flexible numeric type

Lee McCuller lee.mcculler at gmail.com
Fri Aug 17 11:07:33 EDT 2012

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120817/b7d454a9/attachment.html>

More information about the NumPy-Discussion mailing list