>I'm sorry to say that I don't really understand the concept of making the >Python portion only an interface to the >underlying C++ code. Please could you >explain what that means?
David, Sorry, I must not have communicated this well. I'll try again. It depends on how your code works, but the idea is, we generate a shared library with some (large) number of entry points. This is our API, basically. We allow users to program against our API, but there's a ton of other code within the shared library that they don't see, or don't get access to. So, we still generate the C++ shared library, but in addition we generate a layer using Pybindgen that sits on top of the API and exposes it via Python. We didn't have to wrap all the internal function calls in the shared library in Python - that would have been too much work. Instead we built a wrapper around our shared library that implements all the same calls our shared library's API implements, and when they are accessed just makes a call via pybindgen into the existing C++ shared library. Inside the library, we don't care what happens - C++ functions can call other C++ functions, etc - and eventually a result comes back to the python wrapper layer, is translated from C++, and is returned to Python. For something that's more of a program instead of a library, I imagine you could do something similar - instead of wrapping all of your modules or functions, replace the main() function of your program with a python version - and only bother generating a wrapper for the functions called directly from main. I haven't tried the main-replacement bit, but I can verify that for the shared library, it works just fine. -Ben _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
