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.