[Python-Dev] PEP: Adding data-type objects to Python
Travis E. Oliphant
oliphant.travis at ieee.org
Wed Nov 1 20:38:01 CET 2006
Jim Jewett wrote:
> I'm still not sure exactly what is missing from ctypes. To make this concrete:
I was too hasty. There are some things actually missing from ctypes:
1) long double (this is not the same across platforms, but it is a
data-type).
2) complex-valued types (you might argue that it's just a 2-array of
floats, but you could say the same thing about int as an array of
bytes). The point is how do people interpret the data. Complex-valued
data-types are very common. It is one reason Fortran is still used by
scientists.
3) Unicode characters (there is w_char support but I mean a way to
describe what kind of unicode characters you have in a cross-platform
way). I actually think we have a way to describe encodings in the
data-format representation as well.
4) What about floating-point representations that are not IEEE 754
4-byte or 8-byte. There should be a way to at least express the
data-format in these cases (this is actually how long double should be
handled as well since it varies across platforms what is actually done
with the extra bits).
So, we can't "just use ctypes" as a complete data-format representation
because it's also missing some things.
What we need is a standard way for libraries that deal with data-formats
to communicate with each other. I need help with a PEP like this and
that's what I'm asking for. It's all I've really been after all along.
A couple of points:
* One reason to support the idea of the Python object approach (versus a
string-syntax) is that it "is already parsed". A list-syntax approach
(perhaps built from strings for fundamental data-types) might also be
considered "already parsed" as well.
* One advantage of using "kind" versus a character for every type (like
struct and array do) is that it helps consumers and producers speed up
the parser (a fuller branching tree).
-Travis
More information about the Python-Dev
mailing list