[Numpy-discussion] Notes from meeting with Guido regarding inclusion of array package in Python core

Chris Barker Chris.Barker at noaa.gov
Thu Mar 10 14:31:33 EST 2005

Perry Greenfield wrote:
> On Mar 10, 2005, at 6:19 PM, Chris Barker wrote:
>>> a) So long as the extension package has access to the necessary array 
>>> include files, it can build the extension to use the arrays as a 
>>> format without actually having the array package installed.

>>> extension would, when requested to use arrays would see if it could 
>>> import the array package, if not, then all use of arrays would result 
>>> in exceptions.
>> I'm not sure this is even necessary. In fact, in the above example, 
>> what would most likely happen is that the **Helper functions would 
>> check to see if the input object was an array, and then fork the code 
>> if it were. An array couldn't be passed in unless the package were 
>> there, so there would be no need for checking imports or raising 
>> exceptions.
> So what would the helper function do if the argument was an array? You 
> mean use the sequence protocol?

Sorry I wasn't clear. The present Helper functions check to see if the 
sequence is a list, and use list specific code if it is, otherwise, it 
falls back the sequence protocol, which is why it's slow for Numeric 
arrays. I'm proposing that if the input is an array, it will then use 
array-specific code (perhaps PyArray_ContiguousFromObject, then 
accessing *data directly)

> (but presumes that the original code to deal with such things is 
> present; figuring out that a sequence satisfies array constraints can be 
> a bit involved, especially at the C level)

yes, involved, and kind of slow.

If it were me (and for my custom extensions is it), I'd just require 
Numeric, then always call PyArray_ContiguousFromObject and access the 
data array.

Now that I've written that, I have a new idea: use the approach 
mentioned, and check if Numeric can be imported. If so go straight to 
PyArray_ContiguousFromObject every time.

>> It's my experience 
>> that Numeric has not been binary compatible across versions.
> Hmmm, I thought it had been. It does make it much harder to change the 
> api and structure layouts once in, but I thought that had been pretty 
> stable.

I now at least once I tried a Numeric extension (Konrad's netcdf one) 
that had been built with other version of Numeric, and weird results 
occurred. Nothing so obvious as a crash or error, however. You've got to 
love C!


Christopher Barker, Ph.D.
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

More information about the NumPy-Discussion mailing list