Re: embedding, getargs/mkvalue asymmetry

Hammond, Mark (MHammond@jm.cmutual.com.au)
Tue, 14 Feb 95 12:22:00 PST

> >BTW, I'm curious if anyone else has been doing embedding this
> >way (calling functions by module/function name, etc.). Python's
> >embedding utilities don't seem as well-structured as its extending
> >tools; I'd be interested in any ideas on what sort of higher-level
> >embedding API functions might be desirable.
>
> Yes, I am working in this area. When Python is used in any GUI
environment
> (like NT) the main program and the event loop are in C or C++ and are part
> of the operating system. When an event occurs, the Python handler
function
> must be called. That means that in a GUI, Python is necessarily an
> embedded language. But I am not far enough along to comment on specific
> language proposals.

I too have worked extensively with Python in a GUI. I have exactly the same
issues.

My approach is thus:
* Python code "registers" an event. Registry consists of the event itself
(eg, the message) and a Python function object.
* C++ code calls "call_object()" on the object itself.

This means that the C++ code never works in terms of Python function names -
just the objects itself. eg, the Python code:

def func( params ):
pass

window.RegisterMessage( MESSAGE_ID, func )

This passes an object itself to the C++ code, which keeps a reference to it.
The C++ code just has an object *, and never needs to know the name of the
function itself. Note that the Python "member -> function " magic also
works, so class methods also work in the same way.

The total Python API I work with consists of probably less than 1 dozen
functions. Thre basic set consists of only about 3 functions "run_command,
call_object", and the others are utilities like "gettuplesize" or "get_repr"
type functions.

As such, some expanded documentation would be nice, but I dont really think
the API itself needs any expanding.

Mark.