[Numpy-discussion] The array interface published

Scott Gilbert xscottg at yahoo.com
Tue Apr 5 13:35:37 CDT 2005


--- Magnus Lie Hetland <magnus at hetland.org> wrote:
> 
> Do we really have to break backward compatibility in order to add more
> dimensions to the array module?
> 

You're right.  The Python array module could change in a backwards
compatible way.  Possibly using keyword arguments to specify parameters
that have never been there before.

We could probably make sense out of array.insert(), array.append(),
array.extend(), array.pop(), and array.reverse() by giving those an "axis"
keyword.  Even array.remove() could be made to work for more dimensions,
but it probably wouldn't get used often.  Maybe some of these would just
raise an exception for ndims > 1.

Then we'd have to add some additional typecodes for complex and a few
others.

Under the hood, it would basically be a complete reimplementation, but
maybe that is the way to go...  It does keep the number of array modules
down.  I wonder which way would meet less resistance in getting accepted in
the core.  I think creating a new ndarray object would be less risk of
breaking existing applications.

>
> There may be some issues with, e.g., typecode, but still...
>

The .typecode attribute could return the same values it always has.  The
.__array_typestr__ attribute would return the new style values.  That's
confusing, but probably unavoidable.  It would be nice if there was only
one set of typecodes for all of Python, but I think we're stuck with many
(array module typecores, struct module typecodes, array protocol
typecodes). 


Cheers,
    -Scott






More information about the Numpy-discussion mailing list