[boost] Re: [Boost Python Library] Mixing types wrapped in different modules

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-07 19:00:25

> From: "Ullrich Koethe" <koethe_at_[hidden]>
> David Abrahams wrote:
> > This addresses what Prabhu is doing, but I think it leaves the OP (Ralf) out
> > in the cold. He's not interested in cross-module derivation AFAICT. He wants
> > the from_python/to_python functionality from one module to be available in
> > another, so that module A can use module B's wrapped types as parameters and
> > return values.
> 
> Yes, but note that from_python/to_python only works if both modules use
> the same extension_class instances - otherwise, Python would report
> incompatible classes even when the wrapped C++ classes were identical.

That's definitely true of to_python. I'm not so sure about from_python. Really,
that conversion depends on a successful dynamic_cast to the appropriate
instance_holder<T>*. My understanding of dynamic linking and how it interacts
with the C++ runtime is pretty sketchy at best, but I think this just means the
modules need to be dynamically linked with one another.

> So, I think we need common files for the shared stuff even if we don't
> want to inherit.

Common source files? Common headers? Common objects? I'm a bit lost.

> > I think I see a way to do this without the get_window_class() function. I
> > think it also will substantially cut down on code bloat. The usage would be
> > something like:
> > 
> > reswindow_class.declare_base(PyObject_Getattr(PyImport_GetModule("uimodule")
> > , "Window")))
> > 
> 
> This is very nice, and would also ensure that "uimodule" was imported
> before "logicmodule". But again, a downcast is required.

Yeah, but we can hide it. In any case you may have found that this approach
doesn't work.

> > We could provide some nice wrapper functions to insulate users from the
> > direct Python API stuff above. Hint: class_registry doesn't really need to
> > be templated.
> > 
> 
> Why not???

In the current codebase, the only function of the template parameter is to
ensure unique instances; a kind of singleton trick. We could instead get an
instance of the untemplated class_registry from a virtual function in each of
the extension_class_bases participating in declare_base.

> > >
> > > [Note: to make this work, line 33 in module_builder.cpp must be
> > > commented out:
> > >      //    assert(name_holder.get() == 0);
> > > ]
> > 
> > Why? Have you got the latest module_builder.cpp with the destructor
> > ~module_builder?
> > 
> 
> Maybe my sources are outdated. In the version I used, the assertion
> ensures that only one module_builder is constructed in a module.

It used to work that way. The current codebase ensures that only one
module_builder exists at any time.

> But
> after dynamic linking of "logicmodule.so" against "uimodule.so", there
> are two module_builders in "logicmodule.so". This is not an error,
> because uimodule's module_builder is not used in "logicmodule.so".

Probably the best solution would chain the name_holders into a stack, in case a
module might be initialized during another module's initialization.

-Dave