[C++-sig] [Boost.Python v3] Features and Scope

[Jim Bosch]

On 08/27/2011 02:08 PM, Stefan Seefeld wrote:
> On 08/27/2011 04:40 PM, Dave Abrahams wrote:
>>> Hmm.  I'm guessing the global type registry would still be the
>>> default, and per-module registries would override these when
>>> available?  It sounds like Stefan has a clear use case in mind, and
>>> I'd be curious to know what it is.
>> Me too.
>
> I believe what we were discussing at the time was a situation where an
> extension module would not only define converters for its own types, but
> also common types that may are required by the API. This could in
> particular include common types from libstdc++.
>
> If multiple extension modules do this, than a Python program that
> happens to use them in the same application may end up with undefined
> behavior (does this constitute an ODR violation under the hood ?)
>
> To make this work, the common type converters need to be factored out
> and shared. This in itself is impractical (since the original authors
> may not be aware of this need). Furthermore, a converter may require
> module-specific behavior, i.e. converting a std::string in the context
> of one module may be different from the desired conversion in another.
>
> Binding converters to particular modules (and requiring to explicitly
> import / exporting converters) seems like a solution to the above.
>

That's definitely a problem that needs to be addressed.  I've 
encountered it too.  I hope to provide more libstd++ conversions in 
Boost.Python itself, which should alleviate the need for this a bit, but 
it does need a proper solution.

To solve it, I think you'd want anything registered by a specific module 
to appear both in that module's registry and the global registry, with 
the module's registry taking precedence.  Are there any cases where 
you'd want something only to appear in the module-specific registry?

Jim