[C++-sig] multiply defined to_python_converter

[David Abrahams]

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

> I think we definitely did go too far. The more I think about it the more I am
> surprised that we missed this important point until now.
>
> Your import<> idea looks interesting. Here is another wild idea:
>
> Tie the conversions to scope(). If a function is def'ed in scope
> a.b.c look for conversions in c first, then b, then a. It's not
> clear to me what to do about cross-package conversions. Maybe one
> could use a special module-level variable, like

I think Ralf and I are now agreeing on a scheme something like the one
he suggests above.  I don't think we can use scope() exactly, but the
following should be possible:

  * Conversions registered in by the current extension module will
    always be used in preference to those registered by any other
    extension module [but see note below]

  * If no conversion is found in the current extension module, the
    fallback is to search converters associated with its parent in the
    package path, and so on, until the package path is empty.

  * If at this point no eligible conversion is found, the global
    conversion registry is searched.

This would allow some nice conversion scoping without requiring any
explicit imports.  Of course, some ability to explicitly "hoist"
conversions out of a deeper package and into one of its parents or
grandparents would be useful.

Note: "separation" of extension modules is actually determined by
"link units".  Modules linked statically into a single executable
(e.g. for embedding Python) would all share a big converter registry
pool.  Under any OS where symbol exports are not explicitly specified
(e.g. most Unices), any modules which were directly dynamically linked
to one-another would also share a converter registry.  Finally, I am
not certain whether the fact that all extension modules are
dynamically linked to libboost_python will affect this or not.  That
will take some experimentation on various platforms to determine.  The
key question is whether two extension modules can end up with separate
copies of the same static member of a class template:

       template <class T>
       struct test { static int x; };
       template <class T> int test<T>::x;

Now when you change test<int>::x in one extension module, does another
extension module see the same value?  We want the answer to be NO in
order to allow some conversion scoping.

How does this sound to everyone?

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