David Abrahams wrote:

Allen Bierbaum <allenb@vrsource.org> writes:

...

Has anyone every used or even tried to use Boost.Python to dynamically create python types at runtime (instead of the standard compile time method)?

I am working on an very large extensible C++ class library that has a reflective interface that I can extend as much as I need. So instead of trying to create an enormous wrapper at compile time (that would be quickly out of date) I have been investigating the possibility of dynamically creating the python class/type wrappers on demand.

So for example if I discovered at run-time that I wanted a wrapper for a class Hello I would:

- Ask Hello's reflective interface for information about the class and it's bases - Create an associated boost.python class object - For each method Hello reports - add method to the wrapper class using signature and method info from Hello

I would also need to handle registering associated smart pointers, etc. The details are definitely complex, but before I get to far into it I was wondering if anyone had done anything similar or had tried and could tell me how it went or if it is impossible with the current system.

Boost.Python is not exactly designed to do that,

That is what I have come to suspect after looking into the depths of the code. It seems that behind the scenes everything to setup the class and methods ends up as standard run-time calls but the specific methods called and parameters passed are all based on compile time logic. So it does look like this would be difficult and most likely impossible without extensions to the code base to support it. Is this an area that anyone else has ever asked about or have you ever toyed with the idea of having run-time capabilities?

and what you're asking isn't possible to do in portable C++ without knowing all of the classes and member function signatures that you might want to wrap at compile-time anyway.

I could be wrong, but I think I will have all this anyway (or be able to get it) through a reflective interface in the library. Basically each run-time class can return a type descriptor object that can return as much information as necessary. I don't pretend to know C++ as well as you though, so maybe I am missing something. Is there some information or knowledge that would be needed that could not be stored and then looked up later at run-time when registering a wrapper?

However, see http://aspn.activestate.com/ASPN/Mail/Message/cpp-sig/2781474

I may be missing something here. I see how this is related, but I think what I want to do is quite different. I effectively want to do exactly what I could do at compile time with the current code but instead delay the creation so I do it on demand (to save compile time, library size and make the code work with new C++ object types that are introduced and dynamic extensions to the library).

You can of course generate Boost.Python wrapping code dynamically and compile it into extension modules that are then loaded into your running Python program :)

That would be fun but I think my users would wonder a little why the CPU and disk are churning so much at startup. :) Thanks, Allen