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

[Jim Bosch]

On 10/05/2011 11:30 AM, Dave Abrahams wrote:
>
> on Wed Oct 05 2011, Jim Bosch<talljimbo-AT-gmail.com>  wrote:
>
>> On 10/05/2011 07:21 AM, Dave Abrahams wrote:
>>
>>> 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.
>>>
>>
>> I have one (perhaps unusual) use case that's extremely important for
>> me: I have a templated matrix/vector/array class, and I want to define
>> converters between those types and numpy that work with any
>> combination of template parameters.  I can do that with compile-time
>> converters, and after including the header everything just works.
>
> Not really.  In the end you can only expose particular specializations
> of the templates to Python, and you have to decide, somehow, what those
> are.
>
>> With runtime conversions, I have to explicitly declare all the
>> template parameter combinations I intend to use.
>
> Not really; a little metaprogramming makes it reasonably easy to
> generate all those combinations.  You can also use compile-time triggers
> to register runtime converters.  I'm happy to demonstrate if you like.
>

The latter sounds more like what I'd want, though a brief demonstration 
would be great.  You're right in guessing that I don't really care 
whether it's a runtime or compile-time conversion.   The key is that I 
don't want to have to explicitly declare the conversions, even if I have 
some metaprogramming to make that easier - I'd like to only declare 
what's actually used, since that's potentially a much smaller number of 
declarations.

>>> 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.
>>
>> I think this might turn into something that approaches the same mass
>> of complexity Niall describes,
>
> Nothing ever needs to be quite as complex as what Niall describes ;-)
>
> (no offense intended, Niall)
>
>> because a Python module can be imported into several places in a
>> hierarchy at once, and it seems we'd have to track which instance of
>> the module is active in order to resolve those scopes correctly.
>
> Meh.  I think a module has an official identity, its __name__.
>
>> I do hope that most people won't mind if I don't implement something
>> as completely general as what Niall has described
>
> No problem.  As the original author I think you should give what I
> describe a little more weight in this discussion, though ;-)
>

Doing something that's only a small modification to the current 
single-registry model is also very appealing from an 
ease-of-implementation standpoint too, and it would also be sufficient 
for my own needs.

I'd like to see what Stefan's ideas are first, of course, and I should 
take a look at some of the code Niall has pointed me at to see if I can 
take some steps towards a design that would meet his needs as well.  But 
at the moment I'm inclined to go with something pretty similar to the 
current design to keep this problem from overshadowing and swallowing 
all the other things I'd like to go into the upgrade.