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? -Travis _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
