[C++-sig] multiply defined to_python_converter

[David Abrahams]

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

> --- David Abrahams <dave at boost-consulting.com> wrote:
>> > How do I work around this problem of "multiply defined
>> > to_python_converter"?
>> 
>> Hmm.  I'm not sure what the best answer is.  Does Python have a
>> warning mechanism?
>
> http://www.python.org/doc/current/lib/module-warnings.html
>
>> Maybe it would be best to maks such multiple
>> definitions trigger a Python warning instead of a hard error.
>
> I am not sure if this is a viable solution. For example there are two plausible
> alternatives for std::vector<> to_python conversions:
>
> - to a Python list or tuple
>
> - implied by class_<std::vector<> >
>
> I am using both alternatives, depending on the value type. Others will have
> different requirements and make different choices. This will lead to
> incompatibilities.
>
> Ways out?
>
> Boost.Python could simply occupy the most prominent ecological niches by
> default, then everybody has to adhere to that. Conflicts will be the exception.
> Unfortunately a fully fledged std::vector<> wrapper is fairly heavy-weight. But
> there is a similar wrapper in the scitbx (flex_wrapper.h; see Boost.Python FAQ)
> if someone wants to take on this chore.
>
> Another idea would be a conversion registry with "context" or "namespaces". Any
> function could be defined in a certain context with associated conversions. But
> I am afraid David will need a BIG grant to implement such a beast.

Let's think about what the design should be before we worry about
actually getting it done. ;-)

In Boost.Python v1, all conversions were "aggressively local".  The
only way to export them was through a relatively cumbersome explcit
construct in both the exporting and importing modules (No offense,
Ralf)!  One thing I worry about a little is that we might have gone
too far in the direction of automatically publishing all conversions
for v2:

  1. Boost.Python extensions (and the Boost.Python library) compiled
  with different compilers *cannot* be used together unless the
  compilers' ABIs match in many respects:

        type_info (or on some platforms, type_info::name) must have
        the same format.

        Object and vtable layout of any types used across modules must
        match exactly.

  2. Since shipping Boost.Python v2, we've discovered problems with
     some EDG front-ends (used in lots of compilers) on those
     platforms which use type_info::name comparison, which even
     prevent modules compiled with the same compiler from
     interoperating properly unless a cumbersome hack is used.  The
     problem is that the compiler will choose different
     representations of a given type_info::name() depending on how the
     type is instantiated.

It's not clear to me how important the ABI issue is, but I can imagine
that it might be quite important.  For example, most Windows compilers
are capable of generating compatible object and vtable layouts in the
single-inheritance case (which covers an important subset of all C++
applications) even though they may have incompatible type_info
formats. 

I'm not really aware of how similar or different different compiler
ABIs are on other platforms, though I think the new ABI developed by a
consortium for IA64 may mean we're evolving towards a common ABI for
many platforms -- making the issue of incompatibility moot.  However,
we're surely not there yet.

Another approach we could have taken for conversions would be to have
all conversions registered in a "local registry" with each module, and
use an explicit import. Something like:

    // Just sketching, here:
    import<Y> import_Y("Foo.Bar.Y");      // Absolute package path
    import<X> import_X("../Foo/Bar.X");   // Relative package path

I realize this is in some sense a step backwards, but I think it's
important to convince ourselves we really have the right solution by
weighing the pros and cons.

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