Travis Oliphant schrieb: > The big difference, however, is that by going this route you are forced > to use the "type object" as your data-format "instance".
Since everything is an object (an "instance) in Python, this is not such a big difference. > This is > fitting a square peg into a round hole in my opinion. To really be > useful, you would need to add the attributes and (most importantly) > C-function pointers and C-structure members to these type objects. Can you explain why that is? In the PEP, I see two C fucntions: setitem and getitem. I think they can be implemented readily with ctypes' GETFUNC and SETFUNC function pointers that it uses all over the place. I don't see a requirement to support C structure members or function pointers in the datatype object. > There are a few people claiming I should use the ctypes type-hierarchy > but nobody has explained how that would be possible given the > attributes, C-structure members and C-function pointers that I'm proposing. Ok, here you go. Remember, I'm still not claiming that this should be done: I'm just explaining how it could be done. - byteorder/isnative: I think this could be derived from the presence of the _swappedbytes_ field - itemsize: can be done with ctypes.sizeof - kind: can be created through a mapping of the _type_ field (I think) - fields: can be derived from the _fields_ member - hasobject: compare, recursively, with py_object - name: use __name__ - base: again, created from _type_ (if _length_ is present) - shape: recursively look at _length_ - alignment: use ctypes.alignment > It was clear to me that we were "on to something". Now, the biggest > claim against the gist of what I'm proposing (details we can argue > about), seems from my perspective to be a desire to "go backwards" and > carry data-type information around with a Python type. I, at least, have no such desire. I just explained that the ctypes model of memory layouts is just as expressive as the one in the PEP. Which of these is "better" for what the PEP wants to achieve, I can't say, because I still don't quite understand what the PEP wants to achieve. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com