A "roadmap" for ctypes wrapping?

[Alaric Haag]

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?

Many thanks for all feedback!

 

[Diez B. Roggisch]

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

 

[Alaric Haag]

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

Thanks for the pointers!

I had hoped others might offer opinions as well, but the cross-post on
the "ctypes" list is idle.

Thanks again!

Alaric