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)

Boost.Python
CABLE
CXX
Sip
SWIG

Pre-selection

Three of the candidates were rejected relatively early on.

CABLE

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.

CXX

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.

SIP

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

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.

Advantages:

Concentrates on C++/Python interfacing, therefore it is tuned to these two languages and their interaction.
Parses C++ using a C++ compiler as a front-end [GCC_XML is an extension to gcc], guaranteeing high quality parsing even for complicated C++ constructs.
Forms part of the Boost library, which has already been adopted as an external package in the LCG.

Disadvantages:

Template meta-programming pushes compilers to their limits; often it is necessary to increase template-depth limit settings of the compiler, memory usage can be vast, compile times are long, error messages are often pure noise.
Only supports C++/Python interfacing.

SWIG

SWIG is probably the original tool of this nature.

Advantages:

Allows interfacing a variety of low level languages besides C++, with a variety of high level languages besides Python.

Disadvantages:

Support for multiple languages on either side of the interface means that C++/Python support is not as focussed as in Boost. (However, the Python/C++ combination is the primary focus of SWIG's main developer.)

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.

Conclusion

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:

Boost 1.30.0
SWIG 1.3.19