Re: Boost.Python Development Projects

From: rwgk_at_[hidden]
Date: 2001-07-19 07:52:24

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> I would be happy to do that, but it's hard to say what the "central 
ideas"
> are. It would help if we could have a little bit of back-and-forth
> discussion about it. For example, if you could ask some specific 
questions,
> Ulli and I could answer them. Then someone could assemble the 
results into a
> document.

List of potential "central ideas":

- Metaclasses: where are the relevant code sections in Boost.Python?
  (Where is the Don Beaudry hook used?)

- What is the role of the Boost.Python class registry?

- What are the to_python/from_python converters?
  (This is something I could explain, based on the
  answeres to the two previous points.)

- Outline the main steps that are executed when a
  class_builder<T> object is instantiated at runtime
  (class_builder<T> ec());

- Outline the main steps that are executed when Python
  sees the statement "ec = SomeExtensionClass()"
  (i.e. when the constructor of a Boost.Python extension
  class is used).

- Outline the main steps that are executed when Python
  sees the statement "x = ec.attribute"

- Outline the main steps that are executed when Python
  sees the statement x() and x is a member function
  (i.e. ec.attribute())

That would be a good start.

The first project that I would pick from the list at
http://cci.lbl.gov/~rwgk/boost.python/projects.html
is to move the class-registry into a separate Python
module (boost_python_registry). This will unify the
local-module (regular) and cross-module to_python/from_python
converters. Then it should be relatively easy to
implement
  1. cross-module support for declare_base
  2. Two versions of the to_python/from_python
     converters:
       a) One based on the inline friend function trick
          that is currently used but not conforming to
          the C++ ISO standard, but has to be maintained
          for compilers that to not support partial
          ordering (Visual C++ 6 and, very sadly, 7).

       b) One based on partial specialization, in combination
          with some form of concept checking.

Does this strategy sound reasonable?

Are there  "central ideas" that are important for implementing
a boost_python_registry module, but that are not included in
the list above?

Thanks!
        Ralf