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

[Philip Semanchuk]

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 python.net>  
> 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.
>> --
>> http://mail.python.org/mailman/listinfo/python-list
>>
> -- 
> http://mail.python.org/mailman/listinfo/python-list