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.
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
