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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-12-17 00:23:24

----- Original Message -----
From: "Scott Snyder" <snyder_at_[hidden]>

> Not really; since for my present application, i'm generating the wrapper
> code automatically, the automatic operator wrapping doesn't really make
> things any easier for me.

I see. Maybe I can convince Ullrich to look at it, since he wrote the
original automatic wrapping system.

> >I am currently re-constructing Boost.Python. I am working with a new
system
> >for doing translation between C++ and Python data types; one which will
> >reduce the size of compiled modules and enable cross-module inheritance.
I
> >thought I was going to be able to migrate in small steps, but it looks
like
> >that would be really difficult. My plan as of now is to work with
> >Python2.2b2 sources, which will allow me to throw away most of the
existing
> >code for implementing extension classes. I am telling you this in case
you
> >want to adjust what you're working on, since some part of the code will
> >undoubtedly go away or change. If you would like to be part of this
> >development effort, I would be more than happy to deal you in.
>
> Ok, thanks for letting me know.
> In the environment i'm in, moving to python 2.2 at this point would be
> pretty painful, at least if i want other people to be able to use my
stuff.
> So i'd be inclined to stay with the present version, unless it's apparent
> that the new way of doing things would substantially simplify what
> i'm trying to do.

I think that you would see some benefits. In any case, maintaining backward
compatibility would be no more complicated than moving the existing
extension class/metaclass system into the new codebase for earlier Python
versions. The new type conversion mechanism is not dependent on Python 2.2.
I would welcome that integration.

> Maybe i should sketch a little of what i'm trying to do.
> For analyzing physics data, we've been using a software package called
`root',
> which is a large C++ class library, tied together with a C++ interpreter.
> Now, C++ is far from my first choice for an interactive scripting
language,
> and further, the C++ interpreter used is very quirky and buggy.

Too bad. If it weren't, the advantages of being able to move code smoothly
between compiled and interpreted C++ would be compelling.

> So i would like to be able to use this code using python a scripting
> language instead of C++.

That sounds like a great application for Boost.Python.

> We also have lots of locally-written code, most of which has not been
> interfaced to Root, which would be useful to use.
> This is what i've been concentrating on first.
> Since i already have tools to parse C++ headers and provide class member
> information,

Are you talking about data members, member functions , or both?

> i've been hoping to decrease the total amount of effort
> by putting together a tool that can, in most cases, automatically write
> the boost wrappers based on the header declarations.

I'm very interested in integrating or cooperating with any technology that
can deduce the wrapping code automatically!

> For the other goal of being able to call root from python, the root
> classes are already wrapped by the C++ interpreter used, and all the
> information about members, etc. is available at runtime.  Thus, i want
> to be able to build the classes dynamically, rather than at compile time,
> as the present boost.python does.

The classes /are/ built dynamically; it's only the type conversion functions
which are generated at compile-time... but based on your contributions I'm
sure you're aware of that, so I guess I need to ask what you really mean.

A preview of the basis for the new system is available in CVS. to see it:
-------------
Go to boost-root and:

cvs update -d -f -rnewbpl boost/python libs/python
cvs update -d -rmpl-development boost/mpl libs/mpl

You'll find a Jamfile in libs/python which builds and runs some tests of the
new system. You could try a Jam invocation with "-sPYTHON_TEST_ARGS=-v
try.run".
-------------

If I have any sense of what you meant above, you might find the new system
easier to cope with in your "dynamic world" because extension classes are
much more uniform. There is no compile-time type information associated with
them at all.

-Dave