Years ago I spent quite a bit of time learning and using SWIG, mostly in the creation of the pyFLTK Fast Light Toolkit wrappers for python. Swig was, and still is an impressive piece of work – Dave Beazely and the other guilty parties have done a lot to make scripting languages more useful. Pyrex is getting a lot of attention lately. People seem to love it, so I gave it a try. I have a python extension that wraps some C++ classes for the Concept II Rowing Machine. The early implementation was in SWIG. I reimplemented the extension using Pyrex. Some thoughts on the results:
- SWIG’s ability to use the .h files cuts down on busy work
- One set of SWIG source files can generate wrappers for multiple languages ( with minor tweaks for each language)
- the SWIG build process is more complicated – more libraries, dependencies, etc
- Python helper code must reside outside of the SWIG extension library, so there is more work in creating a ‘package’ that uses the generated python shadow classes
- SWIG can automatically generate python shadow classes
- PYREX file contains a mixture of C declarations and arbitrary python code
- PYREX generates one .pyd file that contains both the bridge code to C and the python code – I like this simplicity
- PYREX extension builds quicker than the SWIG extensions
- PYREX support for C++ is through a patch supplied by a third party. It works fine for the simple C++ classes I am using
- SWIG C++ is more mature
I wasn’t able to compare sizes of the resulting extensions as I now have different functionality in each version. The Pyrex code being in a single file does make things simpler to manage.
Since it is working well and I have no need to support other scripting languages, the extension will remain in Pyrex. This is not a slam on SWIG and I’m sure in other projects SWIG will be used again.