Easier to wrap C or C++ libraries?

[argo785]

When creating a Python binding to a C or C++ library, which is easier
to wrap, the C lib or the C++ one? Given a choice, if you had to
choose between using one of two libs, one written in C, the other in C+
+ -- both having approximately the same functionality -- which would
you rather deal with from your Python code?

It would seem to me that there's fewer design considerations when
wrapping a library written in C; you just wrap the functions. However,
since Python supports OOP nicely, it might also be that wrapping C++
code *could* also be staightforward... Are there many pitfalls when
having to map C++'s notion of OO to Python?

 

[Daniel Fetchinson]

When creating a Python binding to a C or C++ library, which is easier

to wrap, the C lib or the C++ one? Given a choice, if you had to
choose between using one of two libs, one written in C, the other in C+
+ -- both having approximately the same functionality -- which would
you rather deal with from your Python code?

It would seem to me that there's fewer design considerations when
wrapping a library written in C; you just wrap the functions. However,
since Python supports OOP nicely, it might also be that wrapping C++
code *could* also be staightforward... Are there many pitfalls when
having to map C++'s notion of OO to Python?

There is no question about it in my mind that wrapping C is easier.
Reason being that python is written in C and not C++.

Cheers,
Daniel

 

[Chris Rebert]

When creating a Python binding to a C or C++ library, which is easier
to wrap, the C lib or the C++ one? Given a choice, if you had to
choose between using one of two libs, one written in C, the other in C+
+ -- both having approximately the same functionality -- which would
you rather deal with from your Python code?

It would seem to me that there's fewer design considerations when
wrapping a library written in C; you just wrap the functions. However,
since Python supports OOP nicely, it might also be that wrapping C++
code *could* also be staightforward... Are there many pitfalls when
having to map C++'s notion of OO to Python?

You're asking two separate questions here.

(1) For Python bindings, is it easier to wrap C, or C++ libraries?
As Daniel points out, C is easier to wrap because CPython itself is
written in C, and C++ cannot be linked directly to C.

(2) Is it easier to use C or C++ bindings from Python code?
Interface-wise, the C++ bindings would be easier to work with at the
Python level as they are object-oriented.

In practice, C libraries are usually wrapped because that's easier to
do. However, to compensate for their procedural interface, people
often write another module on top of the raw Python bindings to expose
a public interface that appears more object-oriented, and make the
lower-level module internal/private.

Cheers,
Chris

 

[Diez B. Roggisch]

When creating a Python binding to a C or C++ library, which is easier
to wrap, the C lib or the C++ one? Given a choice, if you had to
choose between using one of two libs, one written in C, the other in C+
+ -- both having approximately the same functionality -- which would
you rather deal with from your Python code?

It would seem to me that there's fewer design considerations when
wrapping a library written in C; you just wrap the functions. However,
since Python supports OOP nicely, it might also be that wrapping C++
code *could* also be staightforward... Are there many pitfalls when
having to map C++'s notion of OO to Python?

The answer is easy: if you use C, you can use ctypes to create a wrapper
- with pure python, no compilation, no platform issues.

Which IMHO makes a strong point for C - if you need OO, it's bolted on
easily using Python itself, by creating some nice wrapper classes.

Diez

 

[argo785]

The answer is easy: if you use C, you can use ctypes to create a wrapper
- with pure python, no compilation, no platform issues.

Which IMHO makes a strong point for C - if you need OO, it's bolted on
easily using Python itself, by creating some nice wrapper classes.

Thanks for the replies, everyone.

After posting I went back and reviewed some of my old C books as well
as the C++ ones. It's interesting and instructive to look back at C++
after you've used languages like Python for a while. I'd forgotten how
complicated C++ code can get.

 

[Hrvoje Niksic]

The answer is easy: if you use C, you can use ctypes to create a
wrapper - with pure python, no compilation, no platform issues.

The last part is not true. ctypes doesn't work on 64-bit
architectures, nor does it work when Python is built with non-gcc Unix
compilers.

 

[Diez B. Roggisch]

The last part is not true. ctypes doesn't work on 64-bit
architectures, nor does it work when Python is built with non-gcc Unix
compilers.

It's not working on Windows with the standard distribution?

I'm sorry for spreading FUD about being no issues at all, that
apparently wasn't right - however, so far I didn't encounter them.

Diez

 

[Thomas Heller]

ctypes works on 64bit systems, too. However it's a pain in the ... back
to write code with ctypes that works across all platforms. I used to use
ctypes for wrapper but eventually I switched to Cython.

I have plans to add the types from the ansi-c standard to ctypes, like these:

stddef.h: ptrdiff_t, size_t, wchar_t
signal.h: sig_atomic_t
stdio.h: FILE, fpos_t, stderr, stdout, stdin
stdlib.h: div_t, ldiv_t
time.h: clock_t, time_t, struct tm

Do you think that would have helped for writing cross-platform wrappers?

Thomas

 

[Hrvoje Niksic]

What sort of problems have you had?

I find as long as I use the same types as the C code actually uses it
all works fine. If on a 64 bit platform long is 64 bits then it will
be under ctypes too.

I apologize for the misinformation that ctypes doesn't work on 64-bit
systems. The project I'm working on doesn't include ctypes, but it
could be because we don't use GCC to build, or because we also need to
support Win64.