|
Original |
Translation |
|
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
|
Problem 2: SWIG generates the following code when generating wrappers to void functions:
|
|
|
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
|
|
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.
|
|
|
1118
|
How do I use Python for CGI?
|
|
|
1119
|
On the Microsoft IIS server or on the Win95 MS Personal Web Server you set up Python in the same way that you would set up any other scripting engine.
|
|
|
1120
|
|
|