C++ and Python

[bressert]

Hi Everyone,

I'm considering about generating some Python Bindings for C++
libraries. What are considered the best tools for doing something like
this? I know that there are SWIG, SIP, Boost.Python, and GCC_XML.

Thanks!

 

[hg]

8 Mar 2007 22:04:48 -0800 skrev (e-mail address removed):

We are doing this quite extensively at work, and have found that in the
long run SWIG is the best solution. OMMV, but if you ask me, the answer
is SWIG.

mvh,

Hi,

Why do you think it is better than ctypes ?

Thanks,

hg

 

[Bjoern Schliessmann]

I'm considering about generating some Python Bindings for C++
libraries. What are considered the best tools for doing something
like this? I know that there are SWIG, SIP, Boost.Python, and
GCC_XML.

Please excuse me for asking the following stupid question ...

I'm planning to buy a car. What is the best brand? I know that there
are Mercedes, Opel, Honda and Ford.

Regards,


Björn

P.S.: Try this googled link and look for the comparation paragraph,
in section "Introduction":
http://www.boost-consulting.com/writing/bpl.html

 

[cptnwillard]

Hi Everyone,

I'm considering about generating some Python Bindings for C++
libraries. What are considered the best tools for doing something like
this? I know that there are SWIG, SIP, Boost.Python, and GCC_XML.

Thanks!

Declare the functions you want to use in Python with 'extern "C"', and
make them available in a dynamic library. Then use ctypes to call them
directly.

Regards,

Willard

 

[Mandus]

8 Mar 2007 22:04:48 -0800 skrev (e-mail address removed):

Hi Everyone,

I'm considering about generating some Python Bindings for C++
libraries. What are considered the best tools for doing something like
this? I know that there are SWIG, SIP, Boost.Python, and GCC_XML.

We are doing this quite extensively at work, and have found that in the
long run SWIG is the best solution. OMMV, but if you ask me, the answer
is SWIG.

mvh,

 

[Gabriel Genellina]

Why do you think it is better than ctypes ?

I won't say SWIG is better than anything, but how would you use ctypes to
create an instance of a class with several levels of inheritance, and then
invoke a virtual method?
You have to mangle all the names (not too bad, can be done in Python
following the rules) but you also need to find the right function pointer
in the virtual method table; and that can't be done without processing the
source code (at least the .h) in order to know the layout and ordering of
the methods.
Let alone inline functions, templates and #define macros.

 

[hg]

I won't say SWIG is better than anything, but how would you use ctypes to
create an instance of a class with several levels of inheritance, and then
invoke a virtual method?
You have to mangle all the names (not too bad, can be done in Python
following the rules) but you also need to find the right function pointer
in the virtual method table; and that can't be done without processing the
source code (at least the .h) in order to know the layout and ordering of
the methods.
Let alone inline functions, templates and #define macros.

I'm not very familiar with the technology as I just have had to modify an
extension here and there.

I guess my question is off topic as a C++ dll / shared lib is not my main
target but rather C: I need to integrate a printer driver and and would
like if possible to avoid all of the .h stuff involved with SWIG (I am not
being sarcastic): if I can setup my prototypes directly in python, why go
through an extra layer ?

Aren't ctypes better suited to such an application ?

hg

 

[Gabriel Genellina]

I'm not very familiar with the technology as I just have had to modify an
extension here and there.

I guess my question is off topic as a C++ dll / shared lib is not my main
target but rather C: I need to integrate a printer driver and and would
like if possible to avoid all of the .h stuff involved with SWIG (I am
not
being sarcastic): if I can setup my prototypes directly in python, why go
through an extra layer ?

Aren't ctypes better suited to such an application ?

Sure, if you have a C (not C++) DLL, using ctypes should be OK.

 

[Alex Martelli]

target but rather C: I need to integrate a printer driver and and would
like if possible to avoid all of the .h stuff involved with SWIG (I am not
being sarcastic): if I can setup my prototypes directly in python, why go
through an extra layer ?

Aren't ctypes better suited to such an application ?

One advantage of solutions generating C code that gets compiled (SWIG,
Pyrex, writing C-API code directly, etc) is that the C compiler can warn
you, or produce compile-time mistakes, for many kinds of programming
errors; with ctypes, you will instead be finding every such error at
runtime, each time by noticing that Python crashed and facing a
substantial amount of debugging and code inspection to find out why.


Alex

 

[Thomas Heller]

One advantage of solutions generating C code that gets compiled (SWIG,
Pyrex, writing C-API code directly, etc) is that the C compiler can warn
you, or produce compile-time mistakes, for many kinds of programming
errors; with ctypes, you will instead be finding every such error at
runtime, each time by noticing that Python crashed and facing a
substantial amount of debugging and code inspection to find out why.

In principle this is true, some points however I would like to point out:

- The ctypes codegenerator, based on GCCXML, is in a pretty good shape.
A lot of boilerplate (Python) code can be generated automatically.
The codegenerator is available from CVS, with 'easy_install ctypeslib'.
GCCXML has to be installed separately.

- Not always does Python crash on programming errors. On windows, calls
to foreign functions are 'protected' by windows structured exception
handling. In other words, most of the time you get a Python traceback
instead of a segfault.

- There are some large libraries and also smaller ones that are already
wrapped with ctypes. PyOpenGL is probably the most promiment example,
comtypes (although still in heavy development) another one.

As the ctypes author I'm of course biased.

Thomas