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.
-Travis
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
