On Sun, Feb 25, 2007 at 01:35:52PM -0800, Dj Gilcrease wrote: > On 2/25/07, Dave Kuhlman <[EMAIL PROTECTED]> 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 _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
