[Python-Dev] PEP: Adding data-type objects to Python (original) (raw)

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

Alexander Belopolsky wrote:

Travis Oliphant <oliphant.travis 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 cint23). 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?

-Travis

More information about the Python-Dev mailing list