[Python-Dev] PEP: Adding data-type objects to Python
"Martin v. Löwis"
martin at v.loewis.de
Tue Oct 31 18:48:33 CET 2006
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
- 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.
More information about the Python-Dev