A "roadmap" for ctypes wrapping?
Diez B. Roggisch
deets at nospam.web.de
Sun Mar 23 20:01:21 CET 2008
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.
More information about the Python-list