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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4