[C++-sig] multiply defined to_python_converter

[David Abrahams]

"Langston, Matthew David" <langston at SLAC.Stanford.EDU> writes:

> If every Boost.Python module had their own registry (as opposed to a
> global registry), wouldn't this solve the problem? It would just mean
> that type conversions for any type other than the Python built-ins
> might be duplicated from time to time.

That would be a problem for class types exposed by users.  In general,
those have to be exposed in one place and there needs to be a single
identifier for the type which can be somehow deduced from its typeid.
Otherwise, a [pointer or reference to] C++ type exposed in one module
could not be passed to a function exposed in another module.

> But this might not be a bad thing, since there are potentially an
> infinite number of ways to convert these more complex types. For
> example, I thought it was obvious that a std::vector<int> should just
> convert to a Python tuple. It never even occurred to me that someone
> might actually want a class_<std::vector<> > instead.
>
> My current problem with the global registry was simply solved by
> commenting out my C++ to_python_converter and recompiling since, in
> this particular instance, I could rely on the third-party library to
> supply the conversion functionality that I needed. However, this
> forces an implicit dependency of my module on the third-party module.
> There is no way for me to distribute my module standalone.

Yep, that's a problem.

> The "explicit is better than implicit" argument would seem to apply
> here. It would be more work for the Boost.Python module writer, but
> they would have full control over their conversions and their
> modules wouldn't have any implicit dependencies on other modules.

Well, for your particular case I tend to support the idea of warning
when two modules define the same converters, and overwriting (or not)
the older converter.  However, I think there are still good arguments
for explicit imports.

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution