|
Original |
Translation |
|
1108
|
In short, you can use the following code to initialize the Python interpreter with your extension module.
|
|
|
1109
|
#include "python.h" ... Py_Initialize(); // Initialize Python. initmyAppc(); // Initialize (import) the helper class. PyRun_SimpleString("import myApp") ; // Import the shadow class.
|
|
|
1110
|
There are two problems with Python's C API which will become apparent if you use a compiler other than MSVC, the compiler used to build pythonNN.dll.
|
|
|
1111
|
Problem 1: The so-called "Very High Level" functions that take FILE * arguments will not work in a multi-compiler environment because each compiler's notion of a struct FILE will be different. From an implementation standpoint these are very _low_ level functions.
|
|
|
1112
|
|
1113
|
Py_INCREF(Py_None); _resultobj = Py_None; return _resultobj;
|
|
|
1114
|
Alas, Py_None is a macro that expands to a reference to a complex data structure called _Py_NoneStruct inside pythonNN.dll. Again, this code will fail in a mult-compiler environment. Replace such code by:
|
|
|
1115
|
return Py_BuildValue("");
|
|
|
1116
|
It may be possible to use SWIG's ``%typemap`` command to make the change automatically, though I have not been able to get this to work (I'm a complete SWIG newbie).
|
|
|
1117
|
Using a Python shell script to put up a Python interpreter window from inside your Windows app is not a good idea; the resulting window will be independent of your app's windowing system. Rather, you (or the wxPythonWindow class) should create a "native" interpreter window. It is easy to connect that window to the Python interpreter. You can redirect Python's i/o to _any_ object that supports read and write, so all you need is a Python object (defined in your extension module) that contains read() and write() methods.
|
|