[Numpy-discussion] basearray / arraykit

Tim Hochberg tim.hochberg at cox.net
Thu May 11 09:45:02 EDT 2006


Travis Oliphant wrote:

> Christopher Barker wrote:
>
>> Travis Oliphant wrote:
>>
>>> 1) Implement a base-array with no getitem method nor setitem method 
>>> at all
>>>
>>> 2) Implement a sub-class that supports only creation of data-types 
>>> corresponding to existing Python scalars (Boolean, Long-based 
>>> integers, Double-based floats, complex and object types).  Then, all 
>>> array accesses should return the underlying Python objects.
>>> This sub-class should also only do view-based indexing (basically 
>>> it's old Numeric behavior inside of NumPy).
>>
>>
>>> Item 1) should be pushed for inclusion in 2.6  and possibly even 
>>> something like 2)
>>
>>
>> + sys.maxint
>>
>> Having even this very basic n-d object in the standard lib would be a 
>> MAJOR boon to python.
>>
>
> I totally agree.   I've been advertising this for at least 8 months, 
> but nobody is really willing to work on it (or fund it).   At least we 
> have a summer student who is going to try and get Google 
> summer-of-code money for it.  If you have any ability to bump up the 
> ratings of summer of code applications.  Please consider bumping up 
> his application.
>
>> However, as I think about it, one reason I'd really like to see an 
>> nd-array in python is as a standard way to pass binary data around. 
>> Right now, I'm working with the GDAL lib for geo-referenced raster 
>> images, PIL, numpy and wxPython. I'm making a lot of copies to and 
>> from python strings to pass the binary data back and forth. If all 
>> these libs used the same nd-array, this would be much more efficient. 
>> However, that would require non-python data types, most notably a 
>> byte (or char, whatever) type.
>>
> Anything in Python would need to define at least a basic bytes type, 
> for exactly this purpose.  So, we are on the same page.
>
> I'm thinking now that the data-type object now in NumPy would make a 
> nice addition to Python as well for a standard way to define 
> data-types.   Then,  Python itself wouldn't have to do anything useful 
> with non-standard arrays (except pass them around), but it would at 
> least have a way to describe them.

On this front, it's probably at least thinking a bit about whether there 
is any prospect of harmonizing ctypes type notation and the numpy 
data-type object. It seems somewhat silly to have (1) array.arrays 
notation for types ['i'. 'f', etc], (2)  ctypes notation for types 
[c_int, c_float, etc] and (3) numpy's notation for types [dtype('<i4'),  
dtype('<f8')].

It's not clear that this is possible. I at least don't see any clean 
ways to consolidate these off the top of my head, but it's probably 
worth throwing a few of our collective neurons at anyway.

-tim








More information about the NumPy-Discussion mailing list