###  | # Boost.Python ## April 2002 Progress Report

## Contents

Accomplishments

Arbitrary Arity Support
New Callback Interface
Call Policies for Construtors
Real Users, Real Bugs
New Insights
Boost.Python V1 Maintenance

What's Missing

## Accomplishments

April was a short month as far as Boost.Python was concerned, since the spring ISO C++ Committee Meeting (and associated vacation) occupied me for the 2nd half of the month. However, a suprising amount of work got done...

### Arbitrary Arity Support

I began using the Boost.Preprocessor metaprogramming library to generate support for functions and member functions of arbitrary arity, which was, to say the least, quite an adventure. The feedback cycle resulting from my foray into Boost.Preprocessor resulted in several improvements to the library, most notably in its documentation.

Boost.Python now supports calls of up to 17 arguments on most compilers. Because most EDG-based compilers have dismal preprocessor performance, I had to "manually" expand the metaprograms for arities from zero to fifteen arguments, and EDG-based compilers with `__EDG_VERSION__ <= 245` only support 15 arguments by default. If some crazy program finds a need for more than the default arity support, users can increase the base support by setting the `BOOST_PYTHON_MAX_ARITY` preprocessor symbol.

### New Callback Interface

I mentioned in last month's report that I wasn't pleased with the interface for the interface for calling into Python, so now it has been redesigned. The new interface is outlined in this message (though the GCC 2.95.3 bugs have been fixed).

### Call Policies for Constructors

On April 2nd, I announced support for the use of call policies with constructors.

### Real Users, Real Bugs

At least two people outside of Kull began actually using Boost.Python v2 in earnest this month. Peter Bienstman and Pearu Pearson both provided valuable real-world bug reports that helped me to improve the library's robustness.

### New Insights

Answering some of Pearu's questions about explicitly converting objects between Python and C++ actually led me to a new understanding of the role of the current conversion facilities. In Boost.Python v1, all conversions between Python and C++ were handled by a single family of functions, called `to_python()` and `from_python()`. Since the primary role of Boost.Python is to wrap C++ functions in Python, I used these names for the first kind of converters I needed: those that extract C++ objects to be used as function arguments and which C++ function return values to Python. The better-considered approach in Boost.Python v2 uses a completely different mechanism for conversions used when calling Python from C++, as in wrapped virtual function implementations. I usually think of this as a "callback", as in "calling back into Python", and I named the converters used in callbacks accordingly: `to_python_callback` and `from_python_callback`. However, as it turns out, the behavior of the "callback" converters is the appropriate one for users who want to explicitly extract a C++ value from a Python object, or create a Python object from a C++ value. The upshot is that it probably makes sense to change the name of the existing `to_python` and `from_python` so those names are available for the user-friendly explicit converters.

Another of Pearu's questions pushes momentum further in the direction of a more-sophisticated overloading mechanism than the current simple-minded "first match" approach, as I suggested last month.

### Boost.Python V1 Maintenance

As much as I'm looking forward to retiring Boost.Python v1, a significant amount of effort has been being spent dealing with support problems; the saying that code rots when left alone is true, and Boost.Python is no exception. Eventually it became obvious to me that we were going to have to invest some effort in keeping V1 healthy while working on V2. Ralf and I have expanded support for various compilers and stabilized the V1 codebase considerably. We discarded the obsolete Visual Studio projects which were causing so much confusion. Still to do before the next Boost release:

1. Update the build/test documentation with detailed instructions for configuring various toolsets.
2. Provide some links to Boost.Python v2 to let people know what's coming.

## What's Missing

Last month I announced that I would implement the following which are not yet complete:

1. Document all implemented features
2. Implement conversions for `char` types. This is implemented but not tested, so we have to assume it doesn't work.

These are my first priority for this month (especially the documentation).

Revised 3 May, 2002

© Copyright Dave Abrahams 2002. All Rights Reserved.