Re: [boost] What are the future plans for Boost.Python?

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-13 07:47:11

----- Original Message -----
From: <edcjones_at_[hidden]>

> Is any further development planned for Boost.Python?

The status right now:

Ralf Grosse-Kunstleve discovered a bug which will affect a wide class of
conforming compilers. We have been working on a fix... actually Ralf has
been doing most of the hard work, with a little input from me and Ullrich
Koethe. This change will have a small but noticeable impact on
backward-compatibility. [ Ralf, how's that coming along? Do you need help?
Probably you'd like me to at least write some documentation... Probably we
should think seriously about solving the "returned reference problem" at the
same time, no?]

My work does not demand any Python right now, (and demands a lot of other
stuff), so enhancements are low on my list of priorities. I think Ralf has
some plans for enhancements, but I'll let him speak for himself.

> I am a newbie at Boost.Python. I am not a newbie at SWIG having
> painfully wrapped some large C libraries. So here are some thoughts.
>
> 1. A good thing about SWIG is that a lot of repetitious code is
> generated automatically. Could code like
>       this_module.def(greet, "greet");
> be generated from
>       std::string greet();
> automatically?

This was discussed (search this thread:
http://groups.yahoo.com/group/boost/message/5621). "Faux-parsing" C++ and
automatically generating wrapper code usually breaks down at some point, for
many reasons. I am not sure how to solve that problem well, so I decided not
to solve it at all. On the other hand, someone who wanted to do this could
easily implement it as a layer on top of boost::python, without even
learning any of the internals. So, be my guest ;-).

> 2. SWIG also partially solves the problem that "pointers have too many
> potential meanings". It takes advantage of the fact that good
> programmers use the same name for the same thing repeatedly. A
> "unsigned char* lut" might always mean a 256 element array of one byte
> integers. For this case, I have to write a piece of Python API code.
> SWIG applies it only to "unsigned char* lut" arguments. Should there
> be some way to instruct Boost.Python, perhaps via a C++ comment, what
> kind of pointer some pointer is?

Since the Python library doesn't read your C++ code (it just gets compiled),
I'm afraid nothing like that can work.

> Is there some way of telling
> Boost.Python (or SWIG) what to do that is better than the SWIG
> "typemap" that I find to be hard to write and understand?
>
> 3. If a C function looks something like
>           void foo(int* array, int length) {...}
> or
>     int* bar(void) {
>          int n;
>          n = something();
>                array = (int*) malloc(n * sizeof(int));
>                do_something(array, n);
>                return array;
>           }
> then I find SWIG pretty much useless. I wrap it by hand. Could
> "ivect","dvect", etc. help with this?

You can always wrap a forwarding function, and call that "foo" in the python
world:

void foofwd(std::vector<int> const& v)
{
    if (v.size() != 0)
        foo(&v[0],v.size());
    else
        foo(0, 0);
}

-Dave