Travis E. Oliphant wrote:
Two packages need to share a chunk of memory (the package authors do not know each other and only have and Python as a common reference). They both want to describe that the memory they are sharing has some underlying binary structure.
As a quick sanity check, please tell me where I went off track. it sounds to me like you are assuming that: (1) The memory chunk represents a single object (probably an array of some sort) (2) That subchunks can themselves be described by a (single?) repeating C struct. (3) You can't just use the C header, since you want this at run-time. (4) It would be enough if you could say This is an array of 500 elements that look like struct { int simple; struct nested { char name[30]; char addr[45]; int amount; } (5) But is it not acceptable to use Martin's suggested ctypes equivalent of (building out from the inside): class nested(Structure): _fields_ = [("name", c_char*30), ("addr", c_char*45), ("amount", c_long)] class struct(Structure): _fields_ = [("simple", c_int), ("nested", nested)] struct * 500 If I misunderstood, could you show me where? If I did understand correctly, could you expand on why (5) is unacceptable, given that ctypes is now in the core? (New and unknown, I would understand -- but that is also true of any datatype proposal, for the people who haven't already used it. I suspect that any differences from Numpy would be a source of pain for those who *have* used Numpy, but following Numpy exactly is ... not much simpler than the above.) Or are you just saying that "anything with a buffer interface should also have a datatype object describing the layout in a standard way"? If so, that makes sense, but I'm inclined to prefer the ctypes way, so that most people won't ever have to worry about things like endianness/strides/Fortan layout. -jJ