Todd Miller writes:
Philip Austin wrote:
Currently libnumarray.h doesn't implement this -- is there another way to compile a multiple file project which initializes the API just once?
Hopefully you got my earlier message about this. Since I CC'ed numpy-discussion and never saw it there, I've included it below. But, assuming you saw it, I think what you need is in CVS now.
Todd, thanks for the quick response. Regarding your header comments: /* Extensions constructed from seperate compilation units can access the C-API defined here by defining "libnumarray_UNIQUE_SYMBOL" to a global name unique to the extension. Doing this circumvents the requirement to import libnumarray into each compilation unit, but is nevertheless mildly discouraged as "outside the Python norm" and potentially leading to problems. Looking around at "existing Python art", most extension modules are monolithic C files, and likely for good reason. */ I'd agree with this sentiment, but with numarray's NDInfo interface I think we were stuck (we have an implementation file for a bunch of boost numarray helper functions that require the API but have static data initializations, so they can't go into a header). With Numeric, we could avoid import_array altogether, and get everything we needed from PyObject_CallObject calls to Numeric to create arrays using zeros or ones, followed by a cast to PyArrayObject* to get the data pointer and fill the array. With numarray, we need (or needed) getNDInfo to do the same thing, mandating an import_libnumarray. Are the plans for the revised interface to behave in the same way as NDInfo? It's not a big deal to us one way or another, but it would simplify Dave Abraham's boost support for numeric/numarray if much of the functionality could be done through python calls from the C side. Thanks, Phil