boost::python in Glom

I recently took another look at boost::python. It was a much better experience than when I first tried boost::python for Glom in 2005, probably because my use of the Python C API in the meantime has helped me understand what boost::python is doing. I have a mostly-done patch to use it in Glom 1.12 (Glom 1.10 will be released soon). This should make the code simpler and much more robust, allowing me to add more Python API to Glom, allowing people to drive more of the Glom UI via scripts.

As a side-effect this will force us to enable C++ exceptions in the Maemo build for Glom 1.12, increasing code size, but that might be less of an issue by then.

I do find the boost::python documentation fragmented and unfocused, spending too much time congratulating itself about its use of various design patterns and generic programming techniques in the implementation, instead of just telling me how to achieve common tasks. It often assumes knowledge of the Python C API, as if it is based on original proposals or internal documentation. Many companies are using boost::python so I’m surprised that none have arranged for more useful documentation to be written. I’d be happy to do it if someone wants to pay for my time.

In fact, boost::python’s API maps closely to the C API, so you probably need to know both, though I hoped that boost::python would make it clearer and more explicit.

However, the people on the boost::python mailing list have been very helpful when the documentation has not been clear or where I have made silly mistakes.

Boost should install pkg-config .pc files

Getting the CFLAGS and LIBS for boost python in your configure.ac is insanely difficult and fragile. There are some .m4 scripts out there, but I can’t get any of them to work. Why on earth don’t they install a .pc file? They can’t all be Windows programmers.

And despite using unstable APIs, they don’t seem to allow parallel installs. For instance, on my Ubuntu Linux system, the headers are directly under /usr/include/ rather than /usr/include/boost-python-1.0/. GNOME gets this stuff right.

The need for parallel installs is even greater for boost::python because there are various possible incompatible configurations, any of which you are likely to find on your system. At the moment you will just get compiler or linker errors (which distro packagers don’t understand) instead of being able to explicitly depend on a specific version with a specific build (which distro packagers could understand).

This will make life difficult for Glom distro packagers, but I think it’s still worth it.

4 thoughts on “boost::python in Glom

  1. “I do find the boost::python documentation fragmented and unfocused, spending too much time congratulating itself about its use of various design patterns and generic programming techniques in the implementation, instead of just telling me how to achieve common tasks.”

    You just described the documentation for most of the boost libraries. I’m not a boost hater or anything and some of the libraries are extremely useful, but a lot of it is “look at this amazingly tricky way I used c++”. (for probably the worst example of this see boost::serialization… take a good idea, make the easy stuff difficult, make the pieces that no one cares about possible, ignore common use cases, and you end up with boost::serialization)

  2. Yup, b::p documentation is really awful… The important parts are spread about lots of different pages in b::p tutorial/reference, wiki.python.org, and countless blogs and forums. Probably owing to that, some details are still unclear to me (how to throw an out-of-range exception in __getitem__? So far I just let the exception from vector::at() bubble up, but it seems unsatisfactory).

    But mostly I think b::p totally rocks. Initially I thought I’d create a whole new API for the Python bindings; but it turned out to be really better to expose the C++ API design directly to Python, including namespaces, classes, base classes, enums… I can now type the C++ code in Python syntax into IPython, and it works – awesome.

  3. oliver, I’m not sure it will answer your question but for out-of-range exceptions, I use the following code in __getitem__:

    PyErr_SetString( PyExc_IndexError, “list index out of range” );
    bp::throw_error_already_set();

    there is a bunch of PyExc_*Error, just search for the appropriate one (PyExc_TypeError, etc.)
    Don’t forget to call throw_error_already_set() or else your exception may be caught later
    (typically on next python instruction…another headache to figure out at the beginning!)

Comments are closed.