[EMAIL PROTECTED] 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.
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
