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.
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.
March 10th, 2009 at 6:59 am
“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)
March 10th, 2009 at 10:00 am
You should try my pet project, PyBindGen (http://code.google.com/p/pybindgen/). Not only does it allow code without exceptions, it does not even support C++ exceptions at all :P