[Numpy-discussion] libnumarray.h and NO_IMPORT_ARRAY

Philip Austin paustin at eos.ubc.ca
Wed Oct 9 11:04:05 EDT 2002

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

More information about the NumPy-Discussion mailing list