A few questions on Boost.Python

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

A few questions on Boost.Python

Bo Jensen-2
Hi,

I have been looking into the best way for me to make a python wrapper for a C++ library. Boost.Python looks nice and seem to fit my needs, but I have a few questions before I dig in deep and do the implementation.

What I want to do :

I have a very thin header only C++ library, which is an extension on top of a c library i.e some of the C++ functions call functions in a C dll/so. So the C++ library only provides a nice way of using the C library with operators and overloading etc. For this library I want to make an python interface, which only should mimic the C++ classes and functions i.e there will be a 1:1 mapping.

Questions :

1) Would Boost.Python be suited for such a task ?

2) What kind of speed can I expect ? I read somewhere that cython was much faster (but it seems to be less portable and flexible).

3) Will I experience problems with types like wchar or long long ?

4) How do I link to my C library ?

5) I also read that Boost.Python is not thread safe, is that true and if yes can it be fixed/hacked ?

6) Regarding portability, will I have to recompile for each python version ?

7) 64 bit is supported right ?

Thanks to anybody providing some insight.

/Bo


_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: A few questions on Boost.Python

Jim Bosch-2
On 01/23/2012 02:35 PM, Bo Jensen wrote:

> Hi,
>
> I have been looking into the best way for me to make a python wrapper for a
> C++ library. Boost.Python looks nice and seem to fit my needs, but I have a
> few questions before I dig in deep and do the implementation.
>
> What I want to do :
>
> I have a very thin header only C++ library, which is an extension on top of
> a c library i.e some of the C++ functions call functions in a C dll/so. So
> the C++ library only provides a nice way of using the C library with
> operators and overloading etc. For this library I want to make an python
> interface, which only should mimic the C++ classes and functions i.e there
> will be a 1:1 mapping.
>
> Questions :
>
> 1) Would Boost.Python be suited for such a task ?
>

Almost definitely.  For this sort of task most people use Boost.Python,
SWIG, or the raw Python C-API.

Boost.Python is my favorite, and probably the favorite of most people on
this list.  The Python C-API (what I think you're calling "cython") is a
lot less automatic; you'll find yourself writing a lot more code, and
doing a lot more memory management.  SWIG can be much more automatic if
your C/C++ interface is sufficiently simple, but it's generally less
safe w.r.t. memory management, it chokes on complex C++, and I find it
much more difficult to debug.

> 2) What kind of speed can I expect ? I read somewhere that cython was much
> faster (but it seems to be less portable and flexible).
>

Note that none of these tools will work with Python interpreters other
than the standard C one - no Jython, no IronPython.

The performance of any of these wrapper tools is largely determined by
how often you cross the C++/Python boundary.  If you have a huge number
of types, you may see more of a performance hit with Boost.Python or
SWIG, because type conversions involve traversing a registry of all the
types.  I wouldn't worry about performance of the wrapper layer unless
you have a good reason to think you need to.

> 3) Will I experience problems with types like wchar or long long ?
>

I don't think wchar* will be automatically converted to Python str or
unicode, the way char* is.

I'm pretty sure long long will be fine, but I have't really tested it much.

> 4) How do I link to my C library ?
>

Any of these tools will create a shared library (.dll, .so, .dylib, etc)
that you link normally with other shared libraries.  Python will load
that library when you import your wrapped module.

> 5) I also read that Boost.Python is not thread safe, is that true and if
> yes can it be fixed/hacked ?
>

Other people on this list know a lot more than I do about this topic.  I
believe the answer depends on whether the multithreaded programming
crosses the C++/Python boundary.

> 6) Regarding portability, will I have to recompile for each python version ?
>

Yes, for Python major releases (2.6 -> 2.7).  No for minor releases
(2.7.2 -> 2.7.3).  I believe this will be more or less the same for any
Python wrapper tool.

> 7) 64 bit is supported right ?
>

Absolutely.

> Thanks to anybody providing some insight.
>

Sure.  Good luck!

Jim
_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: A few questions on Boost.Python

Anders Wallin-2
>> 5) I also read that Boost.Python is not thread safe, is that true and if
>> yes can it be fixed/hacked ?
>>
>
> Other people on this list know a lot more than I do about this topic.  I
> believe the answer depends on whether the multithreaded programming crosses
> the C++/Python boundary.


FWIW, it is quite straightforward to write C++ code that uses e.g.
OpenMP to do work in multiple threads, and then returns results to
python.
I've only done a case where we wait in python for the c++
function(that potentially uses OpenMP or other threading libs) to
finish before continuing.

AW
_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: A few questions on Boost.Python

Niall Douglas
On 24 Jan 2012 at 9:32, Anders Wallin wrote:

> >> 5) I also read that Boost.Python is not thread safe, is that true and if
> >> yes can it be fixed/hacked ?

Not thread *aware* would be more accurate.

> > Other people on this list know a lot more than I do about this topic.  I
> > believe the answer depends on whether the multithreaded programming crosses
> > the C++/Python boundary.
>
> FWIW, it is quite straightforward to write C++ code that uses e.g.
> OpenMP to do work in multiple threads, and then returns results to
> python.
> I've only done a case where we wait in python for the c++
> function(that potentially uses OpenMP or other threading libs) to
> finish before continuing.

Sure that ought to work. Whatever you do though, do NOT call into
python from within an OpenMP expanded piece of code as you'll run
into GIL problems - unless you handle the GIL manually.

Niall

--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no:
472909.



_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig
Reply | Threaded
Open this post in threaded view
|

Re: A few questions on Boost.Python

Wichert Akkerman
In reply to this post by Jim Bosch-2
On 01/23/2012 09:03 PM, Jim Bosch wrote:

> On 01/23/2012 02:35 PM, Bo Jensen wrote:
>> Hi,
>>
>> I have been looking into the best way for me to make a python wrapper
>> for a
>> C++ library. Boost.Python looks nice and seem to fit my needs, but I
>> have a
>> few questions before I dig in deep and do the implementation.
>>
>> What I want to do :
>>
>> I have a very thin header only C++ library, which is an extension on
>> top of
>> a c library i.e some of the C++ functions call functions in a C
>> dll/so. So
>> the C++ library only provides a nice way of using the C library with
>> operators and overloading etc. For this library I want to make an python
>> interface, which only should mimic the C++ classes and functions i.e
>> there
>> will be a 1:1 mapping.
>>
>> Questions :
>>
>> 1) Would Boost.Python be suited for such a task ?
>>
>
> Almost definitely.  For this sort of task most people use
> Boost.Python, SWIG, or the raw Python C-API.
>
> Boost.Python is my favorite, and probably the favorite of most people
> on this list.  The Python C-API (what I think you're calling "cython")
> is a lot less automatic; you'll find yourself writing a lot more code,
> and doing a lot more memory management.  SWIG can be much more
> automatic if your C/C++ interface is sufficiently simple, but it's
> generally less safe w.r.t. memory management, it chokes on complex
> C++, and I find it much more difficult to debug.

Cython is something entirely different: see http://cython.org/ . If you
are basically wrapping a C library I suspect using cython is simpler and
faster. If C++ support in cython is further improved it will be a
serious alternative to boost.python.

Regards,
Wichert.
_______________________________________________
Cplusplus-sig mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/cplusplus-sig