[Tutor] Embedding Python

Dave Kuhlman dkuhlman at rexx.com
Mon Feb 26 19:03:34 CET 2007


On Sun, Feb 25, 2007 at 01:35:52PM -0800, Dj Gilcrease wrote:
> On 2/25/07, Dave Kuhlman <dkuhlman at rexx.com> wrote:
> > If you have not already, you will want to look at SWIG
> > (http://www.swig.org/).  SWIG will generate C or C++ code from a
> > header file containing structs and classes and function
> > declarations.  That generated code can then be compiled and linked
> > to create a shared library (.so on Linux/UNIX or .dll on Windows),
> > which can then be loaded with the Python "import" statement.
> 
> >From what I can tell SWIG cannot be used to create Python modules that
> talk to a running C++ app, which is why I am embedding then extending
> Python, so the import mymodule will only work while my C++ app is
> running

A few additional thoughts, hoping to trigger a solution in your
mind.

SWIG creates Python modules only in the sense that it wraps the
existing implementation of a function (or C++ classes) in the C/C++
code needed to expose those functions or classes so that they can
be imported and used from Python scripts.  But, the implementation
of those functions/classes wrapped by SWIG is *still* in C/C++.  So
they can make calls back into embedding application, as long as
they are linked with the embedding application. (Whether you trust
your users enough to allow them to make C/C++ calls into your
application is an issue you should think about.)

One way of enabling *Python* scripts run by an embedding
application to communicate back with the embedding C/C++
application is to implement a Python module in C/C++ that makes
calls back into the embedding app.  For example, if the embedding
application contains a function named little_task, then you might
implement in C/C++ and expose to Python a module containing a
function wrap_little_task, which calls little_task.  Then, the
embedding C/C++ app can run a Python script which calls
wrap_little_task, which in turn calls little_task (which is back in
the embedding application).

In your case, perhaps, SWIG has wrapped up a function, so that it
can be called from Python.  That, after all is the point of using
SWIG.  But, the implementation of that function, whose declaration
was wrapped and exposed to Python by SWIG, can call any C/C++
function, even one in the embedding application.

One suggestion: Your embedding application runs scripts written in
Python which can import and call both functions exposed by the
embedding application and functions wrapped by SWIG and can pass
values back and forth between them.

And don't forget, SWIG has wrapped up a C/C++ function, let's say,
so that it can be called from Python.  That, after all is the point
of using SWIG.  But, the *implementation* of that C/C++ function,
whose declaration was wrapped and exposed to Python by SWIG, can
call any C/C++ function, even one in the embedding application.

Hope this helps.  And, hope it is not too confused.

Dave

-- 
Dave Kuhlman
http://www.rexx.com/~dkuhlman


More information about the Tutor mailing list