OSCON 2008, Session 10: Python, C++, and SWIG

Interfacing

• Python is C-extensible
• Calling code doesn’t need to know if it’s calling Python or C
• You can deal with objects, raise Python exceptions, call python functions/methods, play with lists and dictionaries, etc.

Extension Modules

• Implemented as shared objects
• Placed in the Python path
• Used with the Python import statement
• Python calls an init function in the C library

But

• You still have to deal with the bas parts of C/C++
• Yet, we can minimize it to just things that need massive optimization
• Unit testing can happen from the Python side

Bad?

• Can be tedious to make this stuff
• You have to write a Python wrapper for every function you want to access
  • Convert input params
  • Call target function
  • Checking for errors
  • Raising Exceptions
  • Converting the return value to something acceptable in Python
• Create Python versions of C constants
• C structs, variables, C++ classes
• Write an initialization function
• Total yuck. I wonder if there’s a better way to do this.…

SWIG

• OMG!
• Simplified Wrapper Interface Generator
• Automates work creating modules, removes tedium
• Allows you to glue C/C++ to Python, and partition your application to the language’s strengths
• You can think of it as a compiler, it reads C/C++ declarations and writes C code implementing the extension
• Support for structs, classes, functions, constants, etc.
• Lots of language extensions
• Understands the C++ Class hierarchy
• Does appropriate type checking of input params, etc.
• Can generate code for C++ templates
• Can generate code to override C++ virtual methods in Python classes

Many things out of the box

• You can customize lots of stuff it does
  • %typemap: controls what C code is generated in wrapper functions that receive or return objects of certain types
  • %extend: Can add new methods to a wrapped class that don’t necessarily exist in the C++ class
  • %inline: Add new C functions that will automatically be wrapped
  • %pythoncode: Emit custom Python code into the wrapper for the current class, or append or prepend it to the Python proxy function
• There’s more too!
• You can define a macro that’s multiple lines without doing line continuation

Modes of operation for Python targets

• Generate nothing but the extension module (just creates the C wrapper)
• Generate the above, and the proxy module. Useful when wrapping C++. Makes the Python classes that look and act like the C++ ones.
• You can make class-based API wrappers for plain old C functions.
• the .i file makes a python script and a c/cpp file. Then you compile it into a shared object

Why not use SWIG

• It doesn’t generate optimized code
• Classes are flattened to a collection of wrapped functions, with OO-ness added back on by the Proxy classes. Hand-coded module would probably use extension types (classes) instead.

But then again, we should use it

• Saves time and lets you focus on the good stuff