[Python-Dev] PEP: Adding data-type objects to Python
Travis E. Oliphant
oliphant.travis at ieee.org
Tue Oct 31 06:10:17 CET 2006
Travis Oliphant wrote:
> Greg Ewing wrote:
>> Travis Oliphant wrote:
>>> Part of the problem is that ctypes uses a lot of different Python types
>>> (that's what I mean by "multi-object" to accomplish it's goal). What
>>> I'm looking for is a single Python type that can be passed around and
>>> explains binary data.
>> It's not clear that multi-object is a bad thing in and
>> of itself. It makes sense conceptually -- if you have
>> a datatype object representing a struct, and you ask
>> for a description of one of its fields, which could
>> be another struct or array, you would expect to get
>> another datatype object describing that.
Yes, exactly. This is what the Python type I'm proposing does as well.
So, perhaps we are misunderstanding each other. The difference is
that data-types are instances of the data-type (data-format) object
instead of new Python types (as they are in ctypes).
> I've tried to clarify this in another post. Basically, what I don't
> like about the ctypes approach is that it is multi-type (every new
> data-format is a Python type).
I should clarify that I have no opinion about the ctypes approach for
what ctypes does with it. I like ctypes and have adapted NumPy to make
it easier to work with ctypes.
I'm saying that I don't like the idea of forcing this approach on
everybody else who wants to describe arbitrary binary data just because
ctypes is included. Now, if it is shown that it is indeed better than a
simpler instances-of-a-single-type approach that I'm basically proposing
then I'll be persuaded.
However, the existence of an alternative strategy using a single Python
type and multiple instances of that type to describe binary data (which
is the NumPy approach and essentially the array module approach) means
that we can't just a-priori assume that the way ctypes did it is the
only or best way.
The examples of "missing features" that Martin has exposed are not
show-stoppers. They can all be easily handled within the context of
what is being proposed. I can modify the PEP to show this. But, I
don't have the time to spend if it's just all going to be rejected in
the end. I need some encouragement in order to continue to invest
energy in pushing this forward.
More information about the Python-Dev