[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