[Python-Dev] PEP: Adding data-type objects to Python
oliphant.travis at ieee.org
Mon Oct 30 23:00:49 CET 2006
Martin v. Löwis wrote:
> Robert Kern schrieb:
>>>As I unification mechanism, I think it is insufficient. I doubt it
>>>can express all the concepts that ctypes supports.
>>What do you think is missing that can't be added?
> I can factually only report what is missing. Whether it can be added,
> I don't know. As I just wrote in a few other messages: pointers,
> unions, functions pointers, packed structs, incomplete/recursive
> types. Also "flexible array members" (i.e. open-ended arrays).
I understand function pointers, pointers, and unions.
Function pointers are "supported" with the void data-type and could be
more specifically supported if it were important. People typically
don't use the buffer protocol to send function-pointers around in a way
that the void description wouldn't be enough.
Pointers are also "supported" with the void data-type. If pointers to
other data-types were an important feature to support, then this could
be added in many ways (a flag on the data-type object for example is how
this is done is NumPy).
Unions are actually supported (just define two fields with the same
I don't know what you mean by "packed structs" (unless you are talking
about alignment issues in which case there is support for it).
I'm not sure I understand what you mean by "incomplete / recursive"
types unless you are referring to something like a node where an element
of the structure is a pointer to another structure of the same kind
(like used in linked-lists or trees). If that is the case, then it's
easily supported once support for pointers is added.
I also don't know what you mean by "open-ended arrays." The data-format
is meant to describe a fixed-size chunk of data.
String syntax is not needed to support all of these things. What I'm
asking for and proposing is a way to construct an instance of a single
Python type that communicates this data-format information in a
More information about the Python-Dev