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

[Stefan Seefeld]

On 10/05/2011 07:21 AM, Dave Abrahams wrote:
> on Tue Sep 20 2011, "Niall Douglas" <s_sourceforge-AT-nedprod.com> wrote:
>
>> On 19 Sep 2011 at 17:03, Jim Bosch wrote:
>>
>>> 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. 
>> Surely not! You'd want to let template specialisaton be the first 
>> point of call so the compiler can compile in obvious conversions, 
>> *then* and only then do you go to a runtime registry.
> I don't understand why you guys would want compile-time converters at
> all, really.  Frankly, I think they should all be eliminated.  They 
> complicate the model Boost.Python needs to support and cause confusion
> when the built-in ones mask runtime conversions.

Indeed, I never understood that myself. At the Python/C++ language
boundary there is no such thing as "compile-time".

>> This also lets one override the runtime registry when needed in the 
>> local compiland. I'm not against having another set of template 
>> specialisations do something should the first set of specialisations 
>> fail, and/or the runtime registry lookup fails.
> There are better ways to deal with conversion specialization, IMO.  The
> runtime registry should be scoped, and it should be possible to find the
> "nearest eligible converter" based on the python module hierarchy.

...combined with some hints users can add to their modules. Again, I
think we should favor explicit conversion policy settings over implicit
ones.

Sorry, I haven't yet managed to find time to sketch this out in any
detail. I hope to be able to do that to help with this project, though.

Thanks,
        Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...