[Numpy-discussion] libnumarray.h and NO_IMPORT_ARRAY

[Todd Miller]

Philip Austin wrote:

>
>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).  
>
Long term, you would be better off ditching NDInfo and working with the 
Numeric compatability API.  Since it's a subset of the Numeric API, it 
may not support your purposes.  However, if it doesn't,  I want to 
extend it until it does.

>
>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?
>
The current plan is to deprecate the "native" APIs which make use of 
NDInfo and to make numarray as compatible as possible with Numeric.   
 The bulk of the changes which make this reasonable are in numarray CVS 
now.  In a nutshell, prior to our use of C basetypes, we needed 
something like NDInfo.  Now that we're using C basetypes,  NDInfo 
appears less efficient, less compatible, and more complex than the 
"Numeric compatability" interface.   Its possible for our "basetypes" to 
appear to be Numeric arrays, so that's what we did.  If you guys find 
that you need missing parts of the Numeric C-API,  I'll add them to 
numarray.   So far, I've just added what I needed or knew someone else 
needed.

>  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.
>
Can you send me the Numeric wrapper code or let me know where to get it?

>
>Thanks, Phil
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Numpy-discussion mailing list
>Numpy-discussion at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
Thanks,
Todd

-- 
Todd Miller 			jmiller at stsci.edu
STSCI / SSB