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