[C++-sig] same to_python_converter in multiple modules?

[David Abrahams]

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > These are all good questions. Right now, I think the behavior is to
assert
> > if you supply two to_python converters for the same type. Since
conversions
> > go into a global registry and since there are no criteria upon which to
> > choose a to_python conversion other than the source type, it is treated
as
> > an error to register two converters for the same type. What would the
> > most-useful behavior be? You can of course avoid multiple registrations
by
> > creating a common shared library (or Python module if need be) which
> > registers the converter and sets a global variable to prevent multiple
> > registration.
>
> Common shared library sounds OK, but the global variable is redundant.

Only if you're using static initializers to register the converter, or if
the module load order is deterministic (but then, you could always register
the converter from the first module).

> How
> about enriching the Boost.Python interface:
>
>   boost::python::to_python_converter<
>     boost::array<int, 3>, bpl::boost_array_to_tuple<int, 3> >(
>       boost::python::do_nothing_if_already_registered());
>
> If the alternative as an assert, even that is redundant, but makes it
clear
> what will happen and it leaves the door open for future more
sophisticated
> mechanisms.

I'm not sure whether that's enriching or en-crufting the interface. It
certainly could encourage people to make lots of extension modules with
duplicate converters, which in turn could make their modules bigger and
compilation slower. I'd like to think about this some more and/or hear some
other ideas.

-Dave