Very complex Python/C++ embedding/extension question(s)

[Bernhard Glueck]

Hi there
I am developing a new multimedia/game/vr architecture, and at the moment i
am trying to embed python as a scripting language. I have a slew of
questions about the Python/C API..

At first let me elaborate on my unique architecture. In my
"engine" as i call it an application is built using "Actors" which are
Classes that interact over a "reflection system".  This has been implemented
using a custom template based code on the C++ side, but was written so that
any language could interact with it.

Every Actor derives from teh C++ class "Actor" which defines some basic
operations and the call protocl..
e.g actor.Call("MyMethod",arg1,arg2,arg3); will call the method "MyMethod"
on the actor using the arguments passed.  This is achieved by having a type
descriptor for every Actor that is stored in a global list. The type
descriptor dervies from the base class "Type" and knows which methods a
class has.

e.g
class MyActor: public Actor
{
}

has a type descriptopr

class MyActorType : public Type
{
};

that is registered into the global type list.
Then when one calls a method on an actor the appropriate type descriptor is
retrieved from the global list and the method is caleld using the
descriptor.

So far so good .. This works like a charm, and since the type descriptors
are defined using some easy to use macros, writing new classes is very easy,
and allows actors to be defined in extension modules (DLL files on windows )
for my engine. In fact the main engine only contains one actor for loading
DLL files .. all the actors are in other DLLs... this way i can seperate my
modules very nice, and extend the engine at runtime..

Actors are then instantiated using XML and put together to achieve
functionality.

Again this works nice.. Actors are by the way internally stored using a
smartPointer class of mine for automatic reference counting/garbage
collection..

Now i want to extend my engine using Python so that Actors can also be
written in Python , and existing actors can be derived from in Python, as
well as Python Actors can be called from C++ in the same way as others..

I wanted to do this that way derive a "PythonType" class from "Type" and
store any classes that derive directly or indirectly from C++Actor in it ..
so that PythonType works the same way as MyActorType but for all Python
classes in the script files.This would allow me to treat python actors like
C++ actors ( for my tools especially like the editor for game levels )

How would one go about this ? I would need to find out all classes that are
currently in the (embedded ) python interpreter, check if it derives from
the C++Actor class,and if yes generate an instance of PythonType for it
which would know the methods of the python class..

How to do this ?

Second, i would need to export the C++ Actor base class and all other C++
Actor derived classes to python, so that one can write an actori n python
that derives from
one of the already written C++ actors..
I know of all the Wrapper generates etc, and read the tutortials on
embedding and extending python, but note that i do not know at COMPILE Time
of the C++ part which actors are there ( since new modules can be loaded at
runtime ) so this export process needs to be dynamic..... Any ideas ?

And third.. Since the engine deals with actors only, and does not know the
exact type, the python actors would have to have methods like

def MyMethod( actor )

which is just an Actor Smart Pointer wrapped....
Is it possible to have a "method hook" in (with the PythonC API)  that would
be caleld every time i try to invoke a method on this actor ?  This way i
could check the actor concrete type, and determine which methods it has ...
e.g so
that
actor.DoSomething() Would internally use the actor.Call("DoSomething" )
protocol in C++ ..... just translating native Python code to my own method
of calling methods on classes(actors) Remeber i do not know at compile time
which methods an actor supports..... so this would need to be done using
some sort of MethodCallHook.....