[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 mailing list