A "roadmap" for ctypes wrapping?

[Diez B. Roggisch]

Alaric Haag schrieb:
> Hi all,
> 
> I'm undertaking a pretty significant wrapping project (a linux 
> shared-object lib) early in my Python experience, and thought it might 
> be useful for many more that just myself if this thread were to produce 
> a sort of roadmap for approaching wrapping with ctypes.
> 
> I've been doing some reading, but want to verify my "big picture view" 
> and have come to make the following presumptions: (so, please correct me 
> where erroneous)
> 
> - One gathers the ".h" header(s) for the library to determine the data 
> structures (defined in "#define" and "typedef" statements) as well as 
> the prototypes for the library routines.
> 
> - From these header files, one defines attributes to reproduce the 
> "#define" statements, and also reproduces the typedef "structs" by 
> defining classes and assigning a Python list  of tuples for the 
> "_fields_" attribute, to associate a ctype and field name with each 
> field in the "struct".
> 
> - Use ctypes.CDLL to "connect" to the library, and instantiate an object 
> whose attributes are the library routines.
> 
> - From that object, instantiate each of the routines, and override the 
> "argtypes" attribute for each of these with a list of "ctypes", and a 
> single ctype for the "restype" attribute. In either case, the "type" 
> might be a newly-defined type (class) that's more complex than just the 
> provided ctypes.
> 
> Presumably, judicious use of the leading "_" (underscore) is used to 
> hide (make private) the "ugly details" from the wrapper user, revealing 
> only the routines, and possibly, classes that describe data types the 
> original API expects the user to need.
> 
> ======
> Can anyone with some "wrapping" experience add/modify/enhance the above?

Use gccxml to gather the typedefs. And look at Gary Bishop's site to see 
some cool helper classes/functions for dealing with ctypes.

Diez