[Python-3000] PEP Draft: Enhancing the buffer protcol

[Thomas Heller]

Travis E. Oliphant schrieb:
> Attached is my current draft of the enhanced buffer protocol for Python 
> 3000.  It is basically what has been discussed except for some issues 
> with non single-segment memory areas (such as a sub-array).
> 
> Comments are welcome.
> 
> -Travis Oliphant


> Additions to the struct string-syntax
> 
>    The struct string-syntax is missing some characters to fully
>    implement data-format descriptions already available elsewhere (in
>    ctypes and NumPy for example).  Here are the proposed additions:
> 
>    Character         Description
>    ==================================
>    '1'               bit (number before states how many bits)
>    '?'               platform _Bool type 

In SVN trunk (2.6), the struct module already supports _Bool, but the
format character used is 't'.  Not a big issue, though, and I like '?'
better.

>    'g'               long double  
>    'F'               complex float  
>    'D'               complex double 
>    'G'               complex long double 

IIUC, in the latest PEP draft you have apparently changed to two-letter codes
for complex types; which is inconsistent with previous conventions in struct.

>    'c'               ucs-1 (latin-1) encoding 
>    'u'               ucs-2 
>    'w'               ucs-4 
>    'O'               pointer to Python Object 
>    'T{}'             structure (detailed layout inside {}) 
>    '(k1,k2,...,kn)'  multi-dimensional array of whatever follows 
>    ':name:'          optional name of the preceeding element 
>    '&'               specific pointer (prefix before another charater) 
>    'X{}'             pointer to a function (optional function 
>                                              signature inside {})
> 
>    The struct module will be changed to understand these as well and
>    return appropriate Python objects on unpacking.  Un-packing a
>    long-double will return a c-types long_double.

This is probably because there is no way for current Python to support
the long double datatype.  The question for ctypes is: How should ctypes
support that?  Should the .value attribute of a c_longdouble have two
components, should it expose the value as decimal, should Python itself
switch to using long double internally, or are there other possibilities?

>  Unpacking 'u' or
>    'w' will return Python unicode.  Unpacking a multi-dimensional
>    array will return a list of lists.  Un-packing a pointer will
>    return a ctypes pointer object.

ctypes does not support pointer objects of non-native byte order;
should they be forbidden?

>  Un-packing a bit will return a
>    Python Bool.
> 
>    Endian-specification ('=','>','<') is also allowed inside the
>    string so that it can change if needed.  The previously-specified
>    endian string is enforce at all times.  The default endian is '='.
> 
>    According to the struct-module, a number can preceed a character
>    code to specify how many of that type there are.  The
>    (k1,k2,...,kn) extension also allows specifying if the data is
>    supposed to be viewed as a (C-style contiguous, last-dimension
>    varies the fastest) multi-dimensional array of a particular format.
> 
>    Functions should be added to ctypes to create a ctypes object from
>    a struct description, and add long-double, and ucs-2 to ctypes.

Well, ucs-4 should probably be added to ctypes as well.  The current ctypes.c_wchar
type corresponds to the C WCHAR type, its size is configuration dependend.

Thomas