[Python-Dev] PEP: Adding data-type objects to Python

Thomas Heller theller at ctypes.org
Tue Oct 31 18:38:01 CET 2006


Travis Oliphant schrieb:
> Greg Ewing wrote:
>> Travis Oliphant wrote:
>> 
>> 
>>>Part of the problem is that ctypes uses a lot of different Python types 
>>>(that's what I mean by "multi-object" to accomplish it's goal).  What 
>>>I'm looking for is a single Python type that can be passed around and 
>>>explains binary data.
>> 
>> 
>> It's not clear that multi-object is a bad thing in and
>> of itself. It makes sense conceptually -- if you have
>> a datatype object representing a struct, and you ask
>> for a description of one of its fields, which could
>> be another struct or array, you would expect to get
>> another datatype object describing that.
>> 
>> Can you elaborate on what would be wrong with this?
>> 
>> Also, can you clarify whether your objection is to
>> multi-object or multi-type. They're not the same thing --
>> you could have a data structure built out of multiple
>> objects that are all of the same Python type, with
>> attributes distinguishing between struct, array, etc.
>> That would be single-type but multi-object.
> 
> I've tried to clarify this in another post.  Basically, what I don't 
> like about the ctypes approach is that it is multi-type (every new 
> data-format is a Python type).
> 
> In order to talk about all these Python types together, then they must 
> all share some attribute (or else be derived from a meta-type in C with 
> a specific function-pointer entry).

(I tried to read the whole thread again, but it is too large already.)

There is a (badly named, probably) api to access information
about ctypes types and instances of this type.  The functions are
PyObject_stgdict(obj) and PyType_stgdict(type).  Both return a
'StgDictObject' instance or NULL if the funtion fails.  This object
is the ctypes' type object's __dict__.

StgDictObject is a subclass of PyDictObject and has fields that
carry information about the C type (alignment requirements, size in bytes,
plus some other stuff).  Also it contains several pointers to functions
that implement (in C) struct-like functionality (packing/unpacking).

Of course several of these fields can only be used for ctypes-specific
purposes, for example a pointer to the ffi_type which is used when
calling foreign functions, or the restype, argtypes, and errcheck fields
which are only used when the type describes a function pointer.


This mechanism is probably a hack because it'n not possible to add C accessible
fields to type objects, on the other hand it is extensible (in principle, at least).


Just to describe the implementation.

Thomas



More information about the Python-Dev mailing list