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 offset).
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 standardized way.