Pyrex, Swig, and Python

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.

This entry was posted in Python. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *