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 -- http://mail.python.org/mailman/listinfo/python-list
