A number of you (who have my sympathy!) have begun to dig in to
Boost.Python's implementation to some degree, usually so you can
accomplish something that isn't exposed in the documented interface.

I'm sure most of you have noticed that it's not always easy to
navigate the internal structure of the library.  I'd like to address
some of that and at the same time give us the tools to solve some
other problems, which I'll discuss at the end.

I propose to divide the library's implementation into several
namespace layers with corresponding subdirectories of boost/python.
These are just rough divisions and I would welcome suggestions for
finer-grained layering, or better names, or...  These layers are
generally ordered from dependencies to dependents.

   core (for lack of a better name) - This is a Python-independent
     layer which contains the framework of the type-converter
     registry, inheritance.hpp which manages base<-> derived class
     conversions, the exception translator framework,
     boost/python/type_id.hpp, and possibly a few components from the
     current boost/python/detail.

   converter - This stuff which handles Python-specific conversion
     mechanics is mostly already segregated in boost/python/converter,
     but it could be better organized.  Almost everything else in the
     library is built upon these capabilities

   function - Wrapping of (member) (function) pointers into Python
     callable objects. Maybe this should be called "callable".

   callback - Invocation of Python callable objects from C++,
     e.g. call_method<...> , call<...>

   api - various namespace-scope functions such as del(), getattr(),
     etc.

   objects - object, str, dict, tuple, list, long_ ...

   classes - specific support for class wrapping, including
     instance_holders, support for smart pointers, etc.

I see great potential in this reorganization.  One thing I'd like to
see happen in the near term is that Pyste might be altered to use some
lower-level components of Boost.Python directly to improve compile
times.  For example, instead of relying on Boost.Python to generate
wrappers for functions and member functions, Pyste might instead
generate function wrappers directly using Boost.Python's type
converters.  I have no doubt that Python executes faster than the
template engine in most C++ implementations!

A longer-term goal is to move enough of the code into the core that we
could easily re-use it to support other interpreted languages besides
Python.

Comments?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig