On 22/07/11 21:37, strattonbrazil wrote: >> Okay, your terminology was confused: you want to extend Python, not your >> application. > > Sorry, after I sent that e-mail, I realized I had already mixed up the > terms, where I should have written "embedding". > >> First of all, you don't technically need distutils: an extension module >> is simply a shared library that you can build like any other library, >> and I'm sure your build system can easily handle that. Then, you can >> probably use bits of distutils to figure out where to install things to. > > Hrmm, this seems like the most practical solution for me right now. > It makes sense to embed python in my application like I originally > planned, where I expose the individual functions I want to expose. > Eventually if I actually want to provide the exposed functions as a > library, I could actually just compile the application to a shared > library instead of an executable (just not using the main function). > The bindings in the C++ code are the same, correct? Only the way > they're built seems different.
There's no difference between using C and C++. Obviously, you always need the correct extern "C" declarations, but IIRC, Python's method definition macros handle that. You could convert your whole application to a Python extension module, expose the main function to Python, and launch the program using a small Python wrapper script. (Or you could embed Python in your application.) > >> Lastly, depending on what your goals are, you might want to consider not >> integrating Python with your application at all, but exposing what >> functionality you want to expose to Python via dbus. You could write a >> skeleton module that exposes dbus proxy objects to Python scripts / >> modules to make life easier. -- http://mail.python.org/mailman/listinfo/python-list
