[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