[Numpy-discussion] Exporting Numpy C functionality to other extension modules

Todd Miller jmiller at stsci.edu
Thu Jan 16 12:06:05 EST 2003


Chris Barker wrote:

>Jack Jansen wrote:
>
>  
>
>>An extension module that knows about this protocol and gets passed an
>>object that it think might be a Numeric array checks whether the object
>>has an __Numeric_C_interface attribute. If so it retrieves it, checks
>>that it is a Cobject, gets the descriptor and tests it for
>>compatibility and if it is compatible gets the cobject pointer and
>>happily calls all the Numeric routines it needs.
>>    
>>
>
>Wow Jack! are single handely going to impliment all my pet projects that
>I'm too stupid to know how to do my self ? (the other one was Universal
>text file support)
>
>I can only barely follow what you're suggesting, but I still have a
>question about it. It seems while this would provide a way ro an
>extension module to identify whether an object was a Numeric array, and
>then get a pointer to it, how would it know the API for dealing with the
>arrays, without the Numeric header file? Or would you have to include
>the header file when compiling, but not need the library at runtime
>unless it was actually used, which seems a reasonable compromise.
>
>If this would work, I think it's a great idea. Short of including
>NumArray with the standard library (which I imagine is a least a couple
>of Python releases away), it would be a great solution for folks that
>are writing extensions that they want to be able take advantage of
>Numeric when it's there, but not require it.
>
>Do any of the primary Numarray developers think this is a good and
>doable idea?
>  
>
Roll out the time machine...  it's already done.

As long as you don't define the macros PY_ARRAY_UNIQUE_SYMBOL or 
NO_IMPORT_ARRAY,  any file that includes arrayobject.h gets a static 
copy of PyArray_API.

If the module executes import_array() at an appropriate time,  normally 
module initialization, but not necessarily,  the static PyArray_API gets 
filled in and becomes usable.    The import_array() call is critical; 
 without it,  API calls through the static PyArray_API are calls to NULL 
and segfault.

I think that if Numeric is not present,  and you call import_array(),   
it will fail quietly but leave the Python error status set.   So it 
might make sense to call PyErr_Clear() after doing import_array().  

>-Chris
>
So it sounds like your whole "weak linkage" scheme is plausible now with 
Numeric (maybe even numarray!), as would be a minimal API module.

1.  We discussed yesterday how to determine if an object is a Numeric 
array w/o even compiling with arrayobject.h.   The important idea there 
was that if Numeric is not present,  the "isarray" (or whatever) 
function will return false rather than segfaulting because the API 
pointer isn't filled in.

2. Call API functions in contexts where you know you're looking at 
Numeric arrays, i.e.,  right after isarray().  This creates a guard 
which prevents you from calling API functions when Numeric is not present.

3.  Call import_array() at some time before using the API functions, 
 possibly at module init time, failing quietly and clearing the error in 
installations where Numeric is not installed.


Todd






More information about the NumPy-Discussion mailing list