[Python-Dev] PEP: Adding data-type objects to Python

[Jim Jewett]

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