[Numpy-discussion] Array interface

Travis Oliphant oliphant at ee.byu.edu
Sun Apr 3 21:21:15 EDT 2005

Magnus Lie Hetland wrote:

>Travis Oliphant <oliphant at ee.byu.edu>:
>>I don't know if you have followed the array interface discussion.   It 
>>is defined at http://numeric.scipy.org
>This very, very good! The numeric future of Python is looking very
>bright, IMO :)
>Some tiny points:
>  - Shouldn't the regexp for __array_typestr__ be
>    '[<>]?[tbiufcOSUV][0-9]+'?
Probably.   Since, I guess you can only have one of < or > .  Thanks..

>  - What are the semantics when __array_typestr__ isn't V[0-9]+ and
>    __array_descr__ is set? Is __array_typestr__ ignored? Or... What
>    would it be used for?
I would say that the __array_descr__ always gives more information but 
not every array implementation will support looking at it.  For example, 
current Numeric (24.0 in CVS) ignores __array_descr__ and just looks at 
the typestr (and doesn't support 'V').  So,  I suspect that another 
array package that knows this may choose something else besides 'V' if 
it really wants Numeric to still understand it. 

Suppose you have a complex short int array with

__array_descr__ = 'V8

>  - Does the description of __array_data__ mean that the discussed
>    bytes type is no longer needed? (If we can use buffers, that
>    sounds very good to me.)
Bytes is still needed because the buffer object is not very good and we 
need a good buffer object in Python for lots of other reasons.  It would 
be very useful, for example to be able to allocate memory using the 
Python bytes object.  But, it does mean less pressure to get it to work.

>  - Why the parentheses around "buffer protocol-satisfying object" in
>    the description of __array_mask__? And why must it be 'b1'? What
>    if I happen to have mask data from a non-array-protocol source,
>    which happens to be, say, b8 (not unreasonable, I think)? Wouldn't
>    it be good to allow any size of these, and just use zero/non-zero
>    as the criterion? Some of the point of this protocol is to avoid
>    copying and using the original data, after all...? (Same goes for
>    the requirement that it be C-contiguous. I guess I'm basically
>    saying that perhaps __array_mask__ should be an array itself. Or,
>    at least, that it could be *allowed* to be...)
I added the mask late last night.  It is probably the least thought out 
portion.  Everything else has been through the ringer a couple more 
times.    My whole thinking is that I just didn't want to explode the 
protocol with another special name for the mask type.  But, saying that 
the mask object itself can  support the array interface doesn't do that, 
so I think that is a good call.

Last night, using the numarray exporter interface and the Numeric 
consumer interface I was able to share data between a Numeric array and 
numarray array with no copying of the data buffers.  It was very nice.


More information about the NumPy-Discussion mailing list