Evaluation of Python/C++ interfacing packages

Executive summary

This Report recommends the development of an interoperability protocol between Boost.Python and SWIG, in order to allow the use of both of these packages within the LCG.

Candidates considered (in alphabetical order)


Three of the candidates were rejected relatively early on.


GCC_XML was originally developed for use by this package. Currently, CABLE only has a Tcl backend, though Python appears to be on the top of the list of future backends. In late 2002, CABLE's author expressed an interest in using using Boost.Python to build a Python backend for CABLE. No progress seems to have been made in this direction. (The addition of Pyste to Boost.Python has resulted in the latter now having its own GCC_XML frontend.) The vapourware nature of the Python backend excludes CABLE from further consideration at this point.


Development of CXX stopped in late 2001. Its dormancy and the fact that other candidates are considerably more complete, eliminate it from more detailed consideration.


Developed specifically to generate and maintain Python bindings to Qt. Documentation for this package is, essentially, non-existent. It has a very small user base, which, in combination with the very specific purpose motivating its author, suggests that SIP is unlikely to respond well to emerging needs of other users.

Boost.Python and SWIG

In contrast to the aforementioned packages, Boost.Python and SWIG are both mature, relatively well documented, with large user bases and have very active development teams. These two packages were therefore selected for deeper scrutiny.

The Grand Final


Boost.Python is based on C++ template meta-programming and targets C++/Python bindings exclusively. The latest release saw the introduction of Pyste, a frontend written in Python, which uses GCC_XML to parse the header files of the library being wrapped, and produces the Boost.Python source code.




SWIG is probably the original tool of this nature.



Feature comparison

Boost SWIG
Simple class; general usage very simple input; single file output file; long compile time; link dependency on Boost input fairly simple; .py and .so output
Function overload fails to resolve double and int, but complies without warning. Works for types which are not implicitly equivalent in C++. Gets it right.
Python overrides virtual functions Gets it right Labelled as "experimental" but seems to work.
Templates In both systems, one must fix the set of allowed specializations, each specialization becoming a new Python type.
Passing/returning std::string Just works, out of the box Must explicitly include std_stding.i
Operators Automatically exposed Need to do more by hand than in Pyste. some operators difficult to get to work.
Default arguments no Pyste support yet. Default values must be in header. Default values must be in header.
Module interdependencies. Converted classes defined in one module automatically available to others as soon as the former is loaded. Converted classes used on a per-module basis.
Iterators Some help is offered, but no Pyste suport yet. Looks like __iter__ must be implemented by hand.
Exception Translation Default translator for standard exceptions exists; user can register custom translators. ...
Namespaces Namespaces are removed by default; the idea being that the python module provides the namespace.
Conciseness of input With Pyste it's excellent; without Pyste everything must be declared by hand. Often the default input (essentially two references to the source header file) is enough.
Edit-debug-test cycle Extremely slow to compile; for larger inputs compiler limits can be reached. Error messages are pure noise - a package called gstlfilt is rumoured to help with this, but it was not used in this evaluation. As good as can be expected of a statically compiled language.
Documentation Tutorial introduction concisely covers most of what is necessary. Reference manual confusing. Takes some effort to find relevant sections, but it gives the impression of being complete.


Boost.Python and SWIG are the leading candidates, by virtue of providing the greatest coverage of features, the most complete documentation, and being under active maintenance and devlopment. Most imaginable features are supported by both, and it seems likely that both systems will continue to improve with time.

Investigation of the technical merits and feature coverage of the two packages, to the level of detail permitted by the time available, revealed no significant differences in their capabilities.

Both packages have already been used successfully within the LCG and related areas, hence relevant code bases using both technologies already exist.

It is therefore recommended that a more detailed analysis of the issues surrounding interoperability of the two technologies be carried out, with the aim of providing a protocol or interoperability layer which will guarantee that bindings created with the aid of one package can be freely mixed with ones built with the other.
This report is based on an evaluation carried out in May 2003. The most recent releases of Boost and SWIG were used: