reference<>class template and the
reftypedef from Boost.Python v1, a simple smart pointer to a Python object. The old v1 typedef "
reference<PyObject>) had to be retired because I thought it would be too confusing given the importance of
boost::ref()to this library. I began a discussionof possible names, and it was eventually decided to rename
handleand supply a default argument so that
refcould be spelled
handle<>without an additional typedef. There were also some interface changes to make it safer and more-efficient to interface with the raw
PyObject*s forced on us by Python's 'C' API. A discussion of those protocols can be found here.
handle<>; its major distinguishing features are that it gives direct access to the underlying object representation through
operator->, and that can be
NULL, both sources of danger. Instead the library provides a class called
object, which encapsulates a valid Python object and provides a similar interface to Python's.
y = x._("foo"); x._("foo") = 1;which was only marginally better than what we've got. Niki Spahiev then pointed out a potential conflict with the macro which GNU Gettext suggests people define. This unfortunate state of affairs forced us into using
attrinstead. I'd still like to find a better interface, but the lack of overloadable C++ operators which aren't already used in Python is an obstacle. The comma operator is still a possibility, but it has the wrong precedence:
y = x,"foo" // error x,"foo" = 1; // error y = (x,"foo"); // ok (x,"foo") = 1; // okWell, I guess we could consider adding that to the interface without removing
attr(), to see how it plays out...
objectclass also provided an opportunity to replace Boost.Python v1's
to_python()as a user-level interface. Instead,
objecthas a templated constructor which can be used to convert any C++ object to Python using the same underlying mechanisms used for the arguments to
Incidentally, the implementation of operator and conversion support for object uncovered an inordinate number of compiler bugs in our targeted platforms. It was a lot more "interesting" than it should have been.
objectimplemented, it was time to begin replacing the ad-hoc implementations of
dictionarysupplied by Boost.Python v1 with something more robust. I started with
listas an example. Because
objectalready provides all of the requisite operators, publicly deriving
listfrom object seemed like a good choice. The remaining issues were what do do about the one-argument list constructor (which in Python attempts to convert its argument to a list), and how to deal converting with
listarguments to wrapped functions. Some of the issues are laid out in this thread. Ultimately, it was decided that
list(x)should do the same thing in C++ as in Python (conversion), while
listarguments should only match Python
listsubclasses). The implementation worked well, and provided a roadmap for the protocol to be used for implementation of the other built-in types.
unsigned long long(and
__int64on MSVC) to/from python conversions was added this month. We also improved handling of numeric overflows when converting, e.g., a Python int to a type with a more limited range of representation.
Revised 13 November, 2002
© Copyright Dave Abrahams 2002.