[Python-Dev] PEP: Adding data-type objects to Python

Nick Coghlan ncoghlan at gmail.com
Tue Oct 31 13:44:26 CET 2006

Travis E. Oliphant wrote:
> 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.

As a hypothetical, what if there was a helper function that translated a 
description of a data structure using basic strings and sequences (along the 
lines of what you have in your PEP) into a ctypes data structure?

> 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.

I think the most important thing in your PEP is the formats for describing 
structures in a way that is easy to construct in both C and Python 
(specifically, by using strings and sequences), and it is worth pursuing for 
that aspect alone. Whether that datatype is then implemented as a class in its 
own right or as a factory function that returns a ctypes data type object is, 
to my mind, a relatively minor implementation issue (either way has questions 
to be addressed - I'm not sure how you tell ctypes that you have a 32-bit 
integer with a non-native endian format, for example).

In fact, it may make sense to just use the lists/strings directly as the data 
exchange format definitions, and let the various libraries do their own 
translation into their private format descriptions instead of creating a new 


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list