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.
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
