[C++-sig] [Boost.Python v3] Conversions and Registries

[Holger Brandsmeier]

Jim,

My answer for 1), 2) for module specific behavior would be that I
would probably not use module specific behavior. In my current project
I separate the code into multiple BOOST_PYTHON_MODULE. So I would want
to use project specific behavior and not behavior specific to the
BOOST_PYTHON_MODULE. I could reorganize the code, but I kind of like
the idea of separating the big python module into several sub-modules.

As for project specific behavior, I would actually want 2) always, and
I would want 1) optionally. So I would like to enable or disable 1)
either in the build tool or with some global python variables.

As for 3) I would prefer the exact match from the global registry. I
assume that this case would appear if a user overloads a function from
python.

-Holger

On Mon, Sep 19, 2011 at 23:03, Jim Bosch <talljimbo at gmail.com> wrote:
> I'd like to restart the discussion on how conversions will work in
> Boost.Python v3.  Here's the starting point:
>
> I'd like to see support for static, template-based conversions.  These would
> be defined by [partial-]specializing a traits class, and I tend to think
> they should only be invoked after attempting all registry-based conversions.
>  Users would have to include the same headers in groups of interdependent
> modules to avoid specializing the same traits class multiple times in
> different ways; I can't think of a way to protect them from this, but
> template-based specializations are a sufficiently advanced featured that I'm
> comfortable leaving it up to users to avoid this problem.
>
> We've had some discussion of allowing different modules to have different
> registries (in addition to a global registry shared across modules).
>  Leaving aside implementation questions, I have a little survey for
> interested parties:
>
> 1) Under what circumstances would you want a conversion that is completely
> limited to a specific module (or a group of modules that explicitly declare
> it)?
>
> 2) Under what circumstances would you want a conversion to look in a
> module-specific registry, and then fall back to the global registry?
>
> 3) Considering that we will have a "best-match" overloading system, what
> should take precedence, an inexact match in a module-specific registry, or
> an exact match in a global registry?  (Clearly this is a moot point for
> to-Python conversion).
>
> Finally, can anyone give me a reason why having a global registry can lead
> to a violation of the "One Definition Rule"?  This was alluded to many times
> in the earlier discussion, and there's no doubt that a global registry may
> lead to unexpected (from a given module's perspective) behavior - but I do
> not understand the implication that the global registry can result in
> formally undefined behavior by violating the ODR.
>
> Thanks!
>
> Jim
> _______________________________________________
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>