|
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
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...
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.
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).
On April 2nd, I announced
support for the use of call policies with constructors.
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.
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.
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:
- Update the build/test documentation with detailed instructions for
configuring various toolsets.
- Provide some links to Boost.Python v2 to let people know what's
coming.
Last month I announced that I would implement the following which are
not yet complete:
- Document all implemented features
- 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
13 November, 2002
© Copyright Dave Abrahams
2002.