How does BGE inheritance work

Question

Following the documentation at: https://docs.blender.org/api/blender_python_api_2_76_2/bge.types.KX_GameObject.html I can extend a game object with:

class Mine( types.KX_GameObject ):

    def __init__( self, old_owner): #Note: where has my argument gone?

         #stuff

def activate( controller ): # Called from Controller

    Mine( controller.owner ) # Note: Object is stored nowhere

But I'm missing what's doing the magic here. Somehow the controller not gets passed as second argument to __init__ but as first and the game object is internally (?) exchanged (?) with mine.

So how is this working exactly? Is there some blender-foo or is this something Python can do for me which I'm not aware of?

EDIT: To make it more clearly: If I do "normal" inheritance in Python this is how it works:

class Parent:

    def __init__( self ):
        self.a = "FOO"

    def talk():
        return a

class Child( Parent ):

    def __init__( self, b ):
        Parent.__init__( self )
        self.b = b

    def talk( self ):
        return self.a + self.b


child = Child( "BAR" )
print( child.talk() )

someglobal[ 'child' ] = child

so the parameter "BAR" gets passed as second argument b to the constructor of class A. The constructor calls the other one from class A and I end up with an instance which I have to store somewhere globally in order to access it from somewhere else.

Compare this to blender's version: The already instantiated object is passed as an argument to the constructor. But it doesn't end up as second argument to __init__ but gets somehow mangled in while the second argument is something else (in fact it seems to be nothing. trying to access it yields in an error). The finally constructed instance is then somehow stored in the global dictionary for objects and replaces the old one.

These somehows and somethings are which I'm interested in. What's happening here?

EDIT2: Taken from the linked documentation:

def __init__(self, old_owner):

# "old_owner" can just be ignored. At this point, "self" is
# already the object in the scene, and "old_owner" has been
# destroyed.

If I only read the python code in this module (my first example) this is not what is supposed to happen python-wise. So what makes self the object and what destroys the old owner? Is this some c-code magic patched into the python interpreter? Or is this some python magic somewhere in KX_GameObject? Or something else?

Answer 1

When inherit an object you will "merge" the attributes, properties, functions:

class Mine( types.KX_GameObject ):

    def __init__( self, old_owner):
        self.life = 100

def activate( controller ): # Called from Controller

    object = Mine( controller.owner )
    print(object.worldPosition) # [0,0,0] KX_GameObject.worldPosition
    print(object.life) # 100

While no inherit:

class Mine():

    def __init__( self):
        self.life = 100

def activate( controller ): # Called from Controller

    object = Mine()
    print(object.worldPosition) # ERROR
    print(object.life) # 100

About, is this something Python can do for me which I'm not aware of? PY classes class-objects

Answer 2

So to answer my own question at least as far as I understand it: The magic is in the C++ code. (But I have never embedded python in C++ and only have a rough understanding whats going on here.)

This is from the sources (148ff): Blender uses for it's own game objects a base class called PyObjectPlus. These classes are references via a proxy class called PyObjectPlus_Proxy.

PyObjectPlus defines a method called 'py_base_new' which is called whenever a new object is created which is based on a game object.

This method checks that the first argument is indeed of the 'cont.owner' type and then replaces the object in memory with the extended one.

So it's not "normal" python at all. This comment is from the Sources (194):

/* invalidate the existing base and return a new subclassed one,
 * this is a bit dodgy in that it also attaches its self to the existing object                      
 * which is not really 'correct' python OO but for our use its OK. */