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

From: rwgk_at_[hidden]
Date: 2000-12-11 10:20:38

There are again new versions of ivect.cpp, dvect.cpp, Makefile and
tst_vects.py at:

    http://cci.lbl.gov/~rwgk/cvs/cvsweb.cgi/bpl_tru64/

Now there are to_python() functions in the BOOST_PYTHON_CONVERSION
namespace that use the function pointers passed in converter structs.

I have tried to cover both cases outlined at the end of my previous
message:

----------------------------------------------------------------
1. All symbols seen by the dynamic loader live in the same scope
----------------------------------------------------------------

Makefile:
# mutually exclusive: comment out exactly one line
#HIDDEN= -hidden
CPPOPTS= $(CPPOPTS) -DDL_ALL_IN_ONE_SCOPE

In this case, to_python() is only declared but not defined. 
Unfortunately,
importing ivect from dvect or vice versa fails. See, e.g., dvect.cpp:

#ifdef DL_ALL_IN_ONE_SCOPE
    //if (PyImport_ImportModule("ivect") == 0)
    //  throw python::error_already_set();
// Result:
// Assertion failed: name_holder.get() == 0, file module_builder.cpp, 
line 33
#endif

The workaround is to import ivect explicitly in tst_vects.py.

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

I guess this would help me, too!

----------------------------------------------------------------------
-----
2. The symbols seen by the dynamic loader do not all live in the same 
scope
----------------------------------------------------------------------
-----

Makefile:
# mutually exclusive: comment out exactly one line
HIDDEN= -hidden
#CPPOPTS= $(CPPOPTS) -DDL_ALL_IN_ONE_SCOPE

In this case, to_python() is a wrapper that imports and uses a pointer
to the actual converter via a PyCObject.

This case works perfectly even without the explicit import ivect at
the beginning of tst_vects.py.

I have not yet tried to import from_python converters. Is this likely
to work in a similar way?

David wrote:
> Finally, I don't think one should pay the price of exporting these
> converters by default, for every class, so I think class_builder<>
> should have an export_converters() member function which does the
> export.

If the PyCObject is not in the module's __dict__, but only generated
"on demand" when the module.class.__converters__ hook is called,
what exactly is price to pay?
If the converters are not provided by default, I would most likely
export everything explicitly anyway. Otherwise I would find myself
having to go back again and again, recompiling modules only to make
the converters accessible. Or worse, I might have to ask the people
who do not want to share the C++ source to send new binaries, only
to get access to the converters.

David suggested:
    import_converters<X> import_x("x", "X");
    import_reference_converters<X> import_x("x", "X");

Can this be done so that the two cases above are covered without the
user having to think about the difference?

Thanks!
        Ralf