[C++-sig] high level overview of boost.python implementation

[David Abrahams]

From: "Joel de Guzman" <djowel at gmx.co.uk>

> >Suggestion: ask specific questions and write down the answers until the
big
> >picture begins to form in your mind, then write the implementation
overview
> >document yourself and contribute it to the project. I'll be happy to add
> >corrections, etc. If it's any consolation, I have to do the same thing
for
> >the Python codebase itself at some point ;-)
> >
>
> It's difficult to make any promises at this point but I think what I can
> do is
> follow this discussion thread more closely (Initiated by Achima of
> course :-)
> and take notes. Then from what I gather, I can draft an "inside BPL"
> documentation. How does that sound? I think such an initiative will give
> me further insights into the library which I *too* really need to have
now.

Sounds great. I will try to throw you all a clue now and again also.

Here's the first: to_python and from_python conversions used to wrap/unwrap
arguments and return values are built on a client-server architecture. Each
extension module that defines conversions registers them with the converter
registry, which is an associative structure indexed on C++ types. These are
the server-side converters.

When a conversion needs to be performed, client-side converters are used.
Associative registry lookups are all perfomed at static initialization
time, and the results (pointers to the corresponding registry entries) are
stored in static data members of class templates parameterized on the C++
types involved in the conversion. Client-side conversions look in these
static data members to find a registered converter that can do the job
requested.

Some special types use client-side converter specializations. Since there
can be only one way to convert a given C++ type to_python, this works well
for built-ins like int, long, char const*, std::string, et al. Using a
specialization saves the mechanics of indirecting into the converter
registry for common cases. Some other special types (e.g. object and coming
soon: list, tuple et al) have only one reasonable from_python conversion
method, and so use specialization for from_python conversions also.

HTH a little,
Dave