Using C++ and ctypes together: a vast conspiracy? ;)

Brian Brian.Mingus at
Thu Jun 4 17:27:11 EDT 2009

Just to expound a bit on pygccxml, which really makes boost worth it.
pygccxml enables you to do all of your binding work from within Python. It
calls gccxml, which is an xml backend to gcc that outputs the parse tree in
an xml format. Pygccxml provides a very high level interface between the gcc
xml representation and the pygccxml boost code generator. It's really a
great thing. You just have to learn to read the code that pygccxml outputs
for boost, and then go back to python and use the high level interface to
modify the code that it outputs. It has all sorts of selectors so you can
operate on all code that has certain arbitrary properties all at the same

Play with it before deciding on swig. It's frikkin' cool :)

On Thu, Jun 4, 2009 at 3:01 PM, Brian <Brian.Mingus at> wrote:

> Well you'll just have to try Boost.Python. There is a pygccxml gui gets you
> started in about 15 minutes. You'll be able to see how well it groks your
> code and what that generated code is.
> Boost is the best. People complain about it because they don't understand
> C++ templates and they don't realize how incredibly well designed it is.
> If you don't know the basics it's this: Boost.Python uses meta template
> programming. This allows it to use the C++ preprocessor for what other
> binding systems generally write a custom tool for. Long compile times are
> not a real problem for anyone - it's easy to set up a compile farm and the
> benefit is that your runtime code is blazing fast.
> In my opinion Boost is more sophisticated, SWIG, etc.. is more of a hack.
> Of course they all help you get the job done.
> On Thu, Jun 4, 2009 at 2:54 PM, Philip Semanchuk <philip at>wrote:
>> 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
>>> libraries
>>> that will be included into the next c++ standard. It's hard to imagine a
>>> better designed python/c++ interface library than Boost.Python. Further,
>>> pygccxml is amazing with regards to scanning your source code using gcc
>>> itself and then using that xml representation to write out the
>>> Boost.Python
>>> code. What more do people in this conversation want?
>> Hi Brian,
>> 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.
>> Cheers
>> Philip
>>> On Thu, Jun 4, 2009 at 2:07 PM, Thomas Heller <theller at>
>>> wrote:
>>>  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 consideration?
>>>> 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 them.
>>>> 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.
>>>> --
>>>>  --
>> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list