python as plugin language

[Lyle Johnson]

> See below. I'm not interested in the main program requesting a service of
> Python. I'm interested in Python requesting a service of the main program
during
> its servicing of a request from the main program. In other words: C calls
Python,
> which in turn calls C.

So you need to use both extending *and* embedding:

 - Your C application can call out to Python because you've embedded a
Python interpreter into the application, and
 - Python can call back into your C application because you've developed a C
extension module that the Python code can import.

> All the cases you cite miss the essential point - how does the Python
> code call a function in the C language program it's embedded in? It's
> relatively easy for the C program to call a pure Python function - it
checks its
> parameters, calculates a result, and returns it.
>
> I'm more interested in being able to expose a complete object model, with
> real, working functions and data. In other words, what you can do with
> Python in a Web browser under Windows using the Active Scripting
interface,
> although that's a specialized, Windows only implementation.

I think your first task is to identify the object model that you want to
expose to Python and then develop a C extension module that implements that.
I like using SWIG (http://www.swig.org) for this, but you could also do it
"by hand" or perhaps using CXX or Boost. Once you've done this, the big
thing that's still missing (as you've pointed out) is a data-level link
between your extension module and the currently-running C application.
That's what I was recommending the use of one or more global "callback"
objects for.

As an example, imagine the C application's purpose is to keep track of the
animals in a zoo. Your C application manages a single "Zoo" object that is
more or less a container of "Animal" objects. Now you've decided that to
enable end-user customization of the application, you'd like to embed a
Python interpreter and let the user write Python scripts to manipulate the
Zoo object.

You might start by developing a Python extension module that exposes Zoo and
Animal classes, as well as a method that retrieves the single, global "Zoo"
instance from the C application. When the user's Python script makes method
calls on that Zoo object, it's actually calling into your C extension module
code, which manipulates the "real" Zoo instance living in the C application.
SWIG calls this approach shadow classes; the Python Zoo instance "shadows"
the C Zoo instance.