From: Kai S. <kai...@gm...> - 2008-07-17 13:02:38
|
On Thu, Jul 17, 2008 at 3:32 AM, Gregory Propf <gre...@ya...> wrote: > Thanks, I looked at the code you linked and the wrapper code. If you > follow the calls in the code you see that you get to SWIG_TypeQueryModule > and that function first looks for the mangled name and then, failing that > looks for the unmangled one. In my case though it doesn't seem to work in > the latter case. There's some stuff about partial vs. full initializations > and I suspect this is the root cause. There isn't much I can say here, unfortunately. The log_py_objects method in that code will print a list of the unmangled types that are currently known to SWIG. But if what you are looking for is not in there, you are on your own, I fear. > I also get the impression that the python interpreter called by > PyRun_SimpleString doesn't see everything you do with calls to the C API > though this doesn't make much sense. For instance just calling > PyImport_ImportModule("mymod") and PyImport_AddModule("mymod") doesn't seem > to work, you need to say "import mymod" in the python code too. Hm ... in our case, the call to PyImport_ImportModule("foo") was necessary to get SWIG properly initialized, so that the cxx_to_py method works. But all the classes or functions inside that module are local to that specific module. They are not available anywhere else in the Python interpreter. You might be able to get around this by using PyRun_String instead of PyRun_SimpleString, allowing you to specify your own Globals and Locals dictionaries: PyObject *module = PyImport_ImportModule("foo"); PyObject *globals = PyModule_GetDict (module); PyRun_String ("...", Py_file_input, globals, NULL); > I'm dynamically linking everything. Is this some linker phenomenon? Same here and it's not a problem. Actually, it's the preferred way, especially when dealing with multiple modules. Kai |