[C++-sig] Using boost.python to get STL containers of PyObect's.
roman.yakovenko at gmail.com
Tue Jun 26 21:15:14 CEST 2007
On 6/26/07, Eric Mahurin <eric.mahurin at gmail.com> wrote:
> Hi, I'm new to the list and coming from using SWIG w/ python. I
> haven't used boost.python, but am considering it because of
> frustration with SWIG.
> With SWIG, I've been able to make changes to some of the existing
> SWIG/STL infrastructure to get to this point:
> * STL containers of a wrapped PyObject* (handles reference counting)
I guess boost::python::object will do this for you
> * Support of using a callable PyObject* as a BinaryPredicate and other
> template function concepts in STL. This allows using a python
> lamda/function/method as the comparison function for various
I am not sure whether this directly supported or not, but small
wrapper around next functions will do the job:
> * python read/write access to STL iterators
We call this indexing suite:
> * wrap any STL algorithm to be used with the above wrapped STL
> iterators. I should have made it work with any python object that
> implemented the python-STL iterator i/f, but for now it has to be one
> of these swig-wrapped STL iterators.
Well, only instantiation could be exposed. I guess this is not
different from any other tool\framework
> Here are the problems:
> * various STL methods are missing, especially some of the overloaded methods.
You can find such problems in this library too
> * STL big-O performance is not alway preserved. I think I've fixed
> the major issues (I've seen O(n**3) when it should be O(n)), but I'm
> sure there are others.
I guess the wrappers preserve the performance, at least I didn't see
> * hacky and incomplete iterator API
Boost.Python provides "Python-like" API for iterators. It doesn't try
to expose 5 iterator categories.
> I'm getting tired of wading through the multiple layers and confusion
> that SWIG puts in to finish this. I think what is most bothersome is
> the way type conversion and overloading is handled. I'd rather see
> SWIG only try to distinguish between overloaded functions/methods by
> number of arguments. You'd be forced to rename otherwise. IMHO,
> overloading by type doesn't mix with a dynamically typed language
> (i.e. duck-typed).
No problem here. Overloading just works. For type conversion take a
look on next link:
> Has anybody done some similar with boost.python?
All the time :-)
C++ Python language binding
More information about the Cplusplus-sig