Armin Rigo wrote:
On Fri, Oct 27, 2006 at 02:05:31PM -0600, Travis E. Oliphant wrote:
This PEP proposes adapting the data-type objects from NumPy for inclusion in standard Python, to provide a consistent and standard way to discuss the format of binary data.
How does this compare with ctypes? Do we really need yet another, incompatible way to describe C-like data structures in the standard library?
Part of what the data-type, data-format object is trying to do is bring together all the disparate ways to represent data that *already* exists in the standard library.
What is needed is a definitive way to describe data and then have
array struct ctypes
all be compatible with that same method. That's why I'm proposing the PEP. It's a unification effort not yet-another-method. One of the big reasons for it is to move something like the array interface into Python. There are tens to hundreds of people mostly in the scientific computing community that want to see Python grow more support for NumPy-like things. I keep getting requests to "do something" to make Python more aware of arrays. This PEP is part of that effort.
In particular, something like the array interface should be available in Python. The easiest way to do this is to extend the buffer protocol to allow objects to share information about shape, strides, and data-format of a block of memory.
But, how do you represent data-format in Python? What will the objects pass back and forth to each other to do it? C-types has a solution which creates multiple objects to do it. This is an un-wieldy over-complicated solution for the array interface.
The array objects have a solution using the a single object that carries the data-format information. The solution we have for arrays deserves consideration. It could be placed inside the array module if desired, but again, I'm really looking for something that would allow the extend buffer protocol (to be proposed soon) to share data-type information.
That could be done with the array-interface objects (strings, lists, and tuples), but then every body who uses the interface will have to write their own "decoders" to process the data-format information.
I actually think ctypes would benefit from this data-format specification too.
Recognizing all these diverging ways to essentially talk about the same thing is part of what prompted this PEP.