[Python-Dev] PEP: Adding data-type objects to Python
oliphant.travis at ieee.org
Tue Oct 31 20:48:28 CET 2006
Martin v. Löwis wrote:
> 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.
I think it actually is. Perhaps I'm wrong, but a type-object is still a
special kind of an instance of a meta-type. I once tried to add
function pointers to a type object by inheriting from it. But, I was
told that Python is not set up to handle that. Maybe I misunderstood.
Let me be very clear. The whole reason I make any statements about
ctypes is because somebody else brought it up. I'm not trying to
replace ctypes and the way it uses type objects to represent data
internally. All I'm trying to do is come up with a way to describe
data-types through a buffer protocol. The way ctypes does it is "too"
bulky by definining a new Python type for every data-format.
While semantically you may talk about the equivalency of types being
instances of a "meta-type" and regular objects being instances of a
type. My understanding is still that there are practical differences
when it comes to implementation --- and certain things that "can't be done"
Here's what I mean by the difference.
This is akin to what I'm proposing
/* whatever you need to represent your instance
Quite a bit of flexibility....
A Python type object (what every C-types data-format "type" inherits
from) has a C-structure
int tp_basicsize, tp_itemsize;
/* Methods to implement standard operations */
PyObject *tp_mro; /* method resolution order */
... /* + more under certain conditions */
Why in the world do we need to carry all this extra baggage around in
each data-format instance in order to just describe data? I can see why
it's useful for ctypes to do it and that's fine. But, the argument that
every exchange of data-format information should use this type-object
instance is hard to swallow.
So, I'm happy to let ctypes continue on doing what it's doing trusting
its developers to have done something good. I'd be happy to drop any
reference to ctypes. The only reason to have the data-type objects is
something to pass as part of the extended buffer protocol.
> 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.
Sure, but where do these function pointers live and where are they
stored. In ctypes it's in the CField_object. Now, this is closer to
what I'm talking about. But, why is not not the same thing. Why, yet
another type object to talk about fields of a structure?
These are rhetorical questions. I really don't expect or need an answer
because I'm not questioning why ctypes did what it did for solving the
problem it was solving. I am questioning anyone who claims that we
should use this mechanism for describing data-formats in the extended
> 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.
O.K. Thanks for putting in the effort. It doesn't answer my real
>>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
I agree with this. I'm very aware of what "can" be expressed. I just
think it's too awkard and bulky to use in the extended buffer protocol
> 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.
Are you saying you still don't understand after having read the extended
buffer protocol PEP, yet?
More information about the Python-Dev