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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-12-11 20:08:46

----- Original Message -----
From: <rwgk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, December 11, 2000 10:20 AM
Subject: [boost] Re: [Boost Python Library] Mixing types wrapped in
different modules

> 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/
>

> 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!

Probably.

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

I don't have an opinion. Maybe.

> 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?

You pay the price of including the code to do this "on demand" work in every
module, whether or not it is actually used.

> 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.

I could show you how to use a class derived from class_builder in place of
class_builder which does the export for you.

> 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?

Maybe. I'll give it some thought. Even if I can do it, I think the user
might actually need to make a distinction at the point of export in the case
where X has no public copy constructor.

Regards,
Dave