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