[C++-sig] Using boost.python to get STL containers of PyObect's.

[Roman Yakovenko]

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
http://boost.org/libs/python/doc/v2/object.html

> * 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
> methods/constructors.

I am not sure whether this directly supported or not, but small
wrapper around next functions will do the job:

http://boost.org/libs/python/doc/v2/call.html
http://boost.org/libs/python/doc/v2/call_method.html

> * python read/write access to STL iterators

We call this indexing suite:

http://boost.org/libs/python/doc/v2/indexing.html
http://www.language-binding.net/pyplusplus/documentation/containers.html

> * 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
something strange

> * 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:
http://www.language-binding.net/pyplusplus/troubleshooting_guide/automatic_conversion/automatic_conversion.html

> Has anybody done some similar with boost.python?

All the time :-)

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/