on Sat Aug 27 2011, Stefan Seefeld <stefan-AT-seefeld.name> 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.
That's currently supported by the global registry. > 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 ?) Essentially, yes. > 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. It might be, but your description of what you're actually proposing is pretty vague, still, so it's hard to tell. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
