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. >> 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 ;-) > - there is a lot of complexity there I think most users don't need, > and I hope he'd be willing to help with that if he does need to deal > with e.g. passing callbacks between multiple interpreters. But I'm > also afraid he might be onto something in pointing out that fixing the > more standard cases might already be more complicated than it seems. Don't let him scare you off. He's a very smart guy, and a good guy, but he tends to describe things in a way that I find to be needlessly daunting. -- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
