[C++-sig] Boost.Python v2: user-accessible from_python conversions

[David Abrahams]

As usual, how best to provide this is a more interesting problem than it
first appears to be.

I think the basic interface should be:

    extract<T>(obj)

where obj is an instance of class object.

I am still trying to decide whether extract should be a class with an
operator T() or operator T const&() conversion, or a function.

A function is easy-to-implement, but has several drawbacks:

    1. Less-efficient for rvalue conversions, since a stored
       T will need to be copied upon return.

    2. No way to find out if the conversion can succeed without
       throwing an exception. If we use a class we can give it a
       .convertible() member function.

A using a class template also has some disadvantages:

    a. Slightly more complicated to implement

    b. extract<T>(obj) might have unexpected results
       if passed to a function template.

    c. conversions are still allowed to throw exceptions if
       convertible() returns false.

I don't consider b. to be a serious problem, but maybe someone will
disagree with me. In the spirit of "it's always easier to give than to take
away" (thanks, Dave Hawkes -- I'm learning!) I think I want to write the
function version.

------

We also need the lvalue_ptr<> class mentioned in
http://aspn.activestate.com/ASPN/Mail/Message/1237812.

There is some question about whether it can act as a full replacement for
back_reference<>, though. The difference is that back_referece<> is capable
of doing rvalue conversions - so it can hold a C++ object which isn't
actually contained within the corresponding Python object. For example, if
you have a vector<double> argument and a converter from Python tuples to
vector<double>, you might use a back_reference<vector<double> > as a
wrapped function parameter instead. Then you'd still be able to find out
what the source object was. It's also worth asking whether this
functionality is actually important.

I also have some problems with any name xxxx_ptr<> for this beast. For one
thing, we discussed the idea that this thing should derive from object.
That means it will never be nil - it will always refer to some Python
object. It will also inherit lots of nice interface to the underlying
Python object such as the ability to be indexed, sliced, etc. That just
takes it a bit too far away from being a pointer for my tastes.

I thought of wrapper<T>, but that's a little semantically strange. It *is*
a wrapper for T, but it is chiefly used to /un/wrap T objects. Furthermore,
it *will* supply at least unary operator* and operator-> to get access at
the held T object. I'm open to suggestions for naming here. So far,
wrapper<T> is the winner, but it's a little too generic for my tastes.

-Dave

+---------------------------------------------------------------+
                  David Abrahams
      C++ Booster (http://www.boost.org)               O__  ==
      Pythonista (http://www.python.org)              c/ /'_ ==
  resume: http://users.rcn.com/abrahams/resume.html  (*) \(*) ==
          email: david.abrahams at rcn.com
+---------------------------------------------------------------+