> 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 )
> ...
> As such, some expanded documentation would be nice, but I dont really think
> the API itself needs any expanding.
I wish I had the luxury of structuring my system the way you
can. It sounds like you really have a Python system, with
'python-on-top', where the GUI API lives as a C extension
layer; embedding only comes up when routing callbacks
generated in a C system back to Python. Right?
Unfortunately, in my case, there's no way to grab onto a Python
executable object ahead of time. It's a big C (well, really C++)
system, which only calls Python functions or expression strings
at strategic spots, to delegate selected validations and actions
to Python. [The idea is to support on-site customization without
shipping C/C++ library source code.]
In your system, Python code "registers" a function object for
call_object. This won't work for me-- no Python code is run until
the embedded routine is invoked. [I'd be happy to rewrite our
framework in Python, but management probably won't bite... :-)]
So, all I've got is a code string, or the module/function
name of a routine. Now, I could pre-import the modules, and
extract the function objects ahead of time (on C++ start-up),
but there seems little point to this, given the application
structure.
Maybe I'm the only one doing embedding this way, but it's hard
to believe it hasn't/won't come up for others. Guido mentions
that he usually gets by with just the C extension tools; we all
should be so lucky! :-)
Mark L.