[Python-Dev] PEP: Adding data-type objects to Python
Alexander Belopolsky
alexander.belopolsky at gmail.com
Thu Nov 2 05:42:14 CET 2006
Travis Oliphant <oliphant.travis <at> ieee.org> writes:
>
> Don't lump those ideas together. Shapes and strides are necessary for
> N-dimensional array's (it's essentially what *defines* the N-dimensional
> array). I really don't want to sacrifice those in the extended buffer
> protocol. If you want to separate them into different functions then
> that is a possibility.
>
I don't understand. Do you want to discuss shapes and strides separately
from the datatype or not? Note that in ctypes shape is a property of
datatype (as in c_int*2*3). In your proposal, shapes and strides are
communicated separately. This presents a unique memory management
challenge: if the object does not contain shape information in a ready to
be pointed to form, who is responsible for deallocating the shape array?
> >
> > If we manage to agree on the standard way to pass primitive type information,
> > it will be a big achievement and immediately useful because simple arrays are
> > already in the standard library.
> >
>
> We could start there, I suppose. Especially if it helps us all get on
> the same page.
Let's start:
1. Should primitive types be associated with simple type codes (short, int, long,
float, double) or type/size pairs [(int,16), (int, 32), (int, 64), (float, 32),
(float, 64)]?
- I prefer pairs
2. Should primitive type codes be characters or integers (from an enum) at
C level?
- I prefer integers
3. Should size be expressed in bits or bytes?
- I prefer bits
More information about the Python-Dev
mailing list