Using C++ and ctypes together: a vast conspiracy? ;)
philip at semanchuk.com
Thu Jun 4 22:54:01 CEST 2009
On Jun 4, 2009, at 4:23 PM, Brian wrote:
> What is the goal of this conversation that goes above and beyond what
> Boost.Python + pygccxml achieve? Boost has published a variety of
> that will be included into the next c++ standard. It's hard to
> imagine a
> better designed python/c++ interface library than Boost.Python.
> pygccxml is amazing with regards to scanning your source code using
> itself and then using that xml representation to write out the
> code. What more do people in this conversation want?
I've only experimented with SWIG (and ctypes for wrapping a C
library). We're not yet sold on using SWIG to wrap our C++ libraries
and so we're exploring alternatives. Before I started with SWIG, I did
some research to see what other folks were using. The arguments I
recall reading that swayed me to try SWIG before Boost were --
- Boost involves more "magic" than SWIG which means it does a bit more
work for you, but when things go wrong (i.e. interface won't compile
or doesn't work as expected) it is very difficult to debug.
- Boost-ed code requires a Boost runtime library. This isn't a
showstopper problem, obviously, but it's a mark against since it adds
yet another prerequisite to our install process.
- Boost's generated code can take a long time to compile.
I don't know what pygccxml adds to the equation, so perhaps some of
those disadvantages disappear with Boost.Python + pygccxml versus just
plain Boost.Python. If you'd like to expound on this, feel free. I'd
appreciate the education.
I don't know about what Boost (or any other tool) generates, but the
interface I got out of SWIG was not pretty. That's no knock on SWIG --
I'm amazed at what it can do. Nevertheless the generated interface has
all the charm of a Babelfish translation. I imagine lots of
autogenerated code looks "babelfish-ed": meaning is preserved, albeit
crudely, but all the idioms are lost and it's eminently clear that it
was not created by a native speaker.
Until there's an interface generation tool that can build an interface
that makes the wrapped library look completely Pythonic, then choosing
a tool will be a matter of choosing which compromises you want to
make. As long as that's true, I think there's room for multiple
library-wrapping packages, just like there's room for more than one
programming language in the world.
> On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller <theller at python.net>
>> Philip Semanchuk schrieb:
>>> Hi Thomas,
>>> We're weighing options for accessing C++ objects via Python. I
>>> know of
>>> SIWG and Boost; are there others that you think deserve
>> I haven't used any of them myself. A common suggestion is SIP,
>> less known are pybindgen and Robin. But there may be many more,
>> and others with more experience might have much more to say about
>> Also there is Roman Yokavenko's pygccxml which has a lot of stuff.
>>> I've been happy with ctypes in my limited exposure to it and would
>>> love to find a way to make that work. This thread has been very
>>> interesting to me.
>> Unfortunately there is no solution in sight, with ctypes.
More information about the Python-list