Martin v. Löwis wrote:
Travis Oliphant schrieb:
So, the big difference is that I think data-formats should be *instances* of a single type.
This is nearly the case for ctypes as well. All layout descriptions are instances of the type type. Nearly, because they are instances of subtypes of the type type:
py> type(ctypes.c_long) <type '_ctypes.SimpleType'> py> type(ctypes.c_double) <type '_ctypes.SimpleType'> py> type(ctypes.c_double).__bases__ (<type 'type'>,) py> type(ctypes.Structure) <type '_ctypes.StructType'> py> type(ctypes.Array) <type '_ctypes.ArrayType'> py> type(ctypes.Structure).__bases__ (<type 'type'>,) py> type(ctypes.Array).__bases__ (<type 'type'>,)
So if your requirement is "all layout descriptions ought to have the same type", then this is (nearly) the case: they are instances of type (rather then datatype, as in your PEP).
The big difference, however, is that by going this route you are forced to use the "type object" as your data-format "instance". This is fitting a square peg into a round hole in my opinion. To really be useful, you would need to add the attributes and (most importantly) C-function pointers and C-structure members to these type objects. I don't even think that is possible in Python (even if you do create a meta-type that all the c-type type objects can use that carries the same information).
There are a few people claiming I should use the ctypes type-hierarchy but nobody has explained how that would be possible given the attributes, C-structure members and C-function pointers that I'm proposing.
In NumPy we also have a Python type for each basic data-format (we call them array scalars). For a little while they carried the data-format information on the Python side. This turned out to be not flexible enough. So, we expanded the PyArray_Descr * structure which has always been a part of Numeric (and the array module array type) into an actual Python type and a lot of things became possible.
It was clear to me that we were "on to something". Now, the biggest claim against the gist of what I'm proposing (details we can argue about), seems from my perspective to be a desire to "go backwards" and carry data-type information around with a Python type.
The data-type object did not just appear out of thin-air one day. It really can be seen as an evolution from the beginnings of Numeric (and the Python array module).
So, this is what we came up with in the NumPy world. Ctypes came up with something a bit different. It is not "trivial" to "just use ctypes." I could say the same thing and tell ctypes to just use NumPy's data-type object. It could be done that way, but of course it would take a bit of work on the part of ctypes to make that happen.
Having ctypes in the standard library does not mean that any other discussion of how data-format should be represented has been decided on. If I had known that was what it meant to put ctypes in the standard library, I would have been more vocal several months ago.