[Python-3000] bytes vs array.array vs numpy.array

Colin J. Williams cjw at sympatico.ca
Mon Oct 15 23:16:08 CEST 2007


skip at pobox.com wrote:
>     Nick> I wouldn't mind seeing some iteration-in-C bit-bashing operations
>     Nick> in there eventually...
>
>     Nick>    data = bytes([x & 0x1F for x in orig_data])
>
> This begins to make it look what you want is array.array or nump.array.
> Python's arrays don't support bitwise operations either, but numpy's do.
> How much overlap is there between the three types?  Does it make sense to
> consider that canonical underlying array type now (or in the near future,
> sometime before the release of 3.0 final)?
>
> Skip

I am a lurker here, rather than a 
contributer but I hope that this
idea will be explored further.

A good canonical multi-dimensional array 
is needed.

NumPy provides a class which, in 
addition to serving various numeric
needs, also provides for a 
multi-dimensional array where the elements
can be of some class/types.

It would be good if array.Array could 
create a multidimensional array, where 
each element would be an instance of 
dtype, which could be any known type or 
class

The Array could have a signature 
something like:
          Array(shape, type, initializer)

          where:
            shape        is a tuple, 
giving the dimensionality
                         (or an integer 
for a single dimension)
            dtype        is a Python 
type or class
            initializer  is a Python 
expression which can be converted into 
an array of dtype, where dtype is any 
known type or class.

Thus, Array(5, float, [0, 1, 2, 3, 4]) 
would have the same effect as the 
current array.array('f', [0., 1., 2., 
3., 4.])

To allow for the full range of data 
types provided by array.array, it would 
be necessary to define a few additional 
Python data types.  The aim here is to 
use meaningful mnemonics, rather than 
obscure letter codes.

Colin W.




More information about the Python-3000 mailing list