Re: [boost] revised Boost.Python inplace operators patch

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-12 19:18:37

----- Original Message -----
From: "Toon Knapen" <toon.knapen_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, December 12, 2001 8:39 AM
Subject: Re: [boost] revised Boost.Python inplace operators patch

> David Abrahams wrote:
>
> >>I'm asking because I'm planning on using it within the next month, and
> >>otherwise I'll minimise this effort and wait for the next release.
> >>
> >
> > Let's discuss what you're going to do. I can let you know whether it
will be
> > a significant transition or not.
>
>
> I'm not sure how to answer this : I just took a look the other day at
> how I can provide python bindings for my program, so I have no extensive
> experience with boost.python and thus can't give you detailed specifics.
>
> Basically, I will create bindings for a set of class hierarchies, using
> function overloading and virtual functions and templates that are
> distributed over a number of libraries (cross extension module
> dependencies). (looking at the table of contents of the Boost.Python
> doc, this is about everything except pickle support I guess).

There may be interface changes, but not gratuitous ones, and transformations
will normally be easy. The basic approach at a user level will remain
similar, though most of the infrastructure will be different.

In particular, the way that type conversions to and from python are done
will be changed to better support cross-module work, including cross-module
inheritance. There will be no need to do anything explicitly to pass types
across modules: the converters will be registered with a central authority
which will dole them out on demand. One side-effect of this is that there
will generally be no compile-time checks for the availability of conversions
to or from a particular type. Despite our predilection for static checking
in the C++ world, I think this is actually a superior arrangement.

Some conversions which are currently done automatically will not be done
automatically anymore. In particular, when you wrap a functions returning a
reference (even a const reference), you will need to explicitly specify how
the result should be handled. The current behavior is to copy the referenced
object into a new Python object, which can silently produce incorrect
behavior.

I would suggest that you get started with Boost.Python now, if only so that
you can give me more informed feedback about what should happen in the next
version ;-)

-Dave