[Python-3000] bytes vs array.array vs numpy.array (original) (raw)

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 origdata]) 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