[Python-Dev] PEP: Adding data-type objects to Python

Travis E. Oliphant oliphant.travis at ieee.org
Thu Nov 2 06:01:50 CET 2006

Alexander Belopolsky wrote:
> 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?  

Perhaps a "view object" should be returned like /F suggests and it 
manages the shape, strides, and data-format.

>>> 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

Are these orthogonal?

> 3. Should size be expressed in bits or bytes?
>     - I prefer bits

So, you want an integer enum for the "kind" and an integer for the 
bitsize?   That's fine with me.

One thing I just remembered.  We have T_UBYTE and T_BYTE, etc. defined 
in structmember.h already.  Should we just re-use those #defines while 
adding to them to make an easy to use interface for primitive types?


More information about the Python-Dev mailing list