[Python-Dev] PEP: Adding data-type objects to Python
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