jyapayne/swig
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Factored some #ifdef noise out of the initialization function by adding

Browse source 
SwigPyBuiltin_SetMetaType.

For %import statements, move the runtime import out of SWIG_init and into the
.py file.  The reason for this is that the import must be executed within the
python execution frame of the module, which is true in the .py file, but *not*
true in the initialization function.  Had to re-order the .py file slightly
to put the 'import' statements at the top; that's necessary to make sure base
types from an imported module are initialized first.  If -builtin isn't used,
then the .py code is not re-ordered.

Added an explanation and workaround for the limitation that wrapped types are
not raise-able.



git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/branches/szager-python-builtin@12585 626c5289-ae23-0410-ae9c-e8d60b6d4f22
This commit is contained in:
Stefan Zager 2011-04-01 19:35:30 +00:00
commit cd7fc2047b
4 changed files with 83 additions and 49 deletions
Download patch file Download diff file Expand all files Collapse all files

63
Doc/Manual/Python.html
View file

@ -2350,14 +2350,71 @@ please refer to the python documentation:</p>
<p>Use of the <tt>-builtin</tt> option implies a couple of limitations:
<ul>
<li>Some legacy syntax is no longer supported; in particular:</li>
<li><p>Some legacy syntax is no longer supported; in particular:</p></li>
<ul>
<li>The functional interface is no longer exposed. For example, you may no longer call <tt>Whizzo.new_CrunchyFrog()</tt>. Instead, you must use <tt>Whizzo.CrunchyFrog()</tt>.</li>
<li>Static member variables are no longer accessed through the 'cvar' field (e.g., <tt>Dances.cvar.FishSlap</tt>).
They are instead accessed in the idiomatic way (<tt>Dances.FishSlap</tt>).</li>
</ul>
<li>Wrapped types may not be thrown as python exceptions</li>
<li>Reverse operators are not supported.</li>
<li><p>Wrapped types may not be thrown as python exceptions. Here's why: the python internals expect that all sub-classes of Exception will have this struct layout:</p>
<div class="code">
<pre>
typedef struct {
PyObject_HEAD
PyObject *dict;
PyObject *args;
PyObject *message;
} PyBaseExceptionObject;
</pre>
</div>
<p>But swig-generated wrappers expect that all swig-wrapped classes will have this struct layout:</p>
<div class="code">
<pre>
typedef struct {
PyObject_HEAD
void *ptr;
swig_type_info *ty;
int own;
PyObject *next;
PyObject *dict;
} SwigPyObject;
</pre>
</div>
<p>There are workarounds for this. For example, if you wrap this class:
<div class="code">
<pre>
class MyException {
public:
MyException (const char *msg_);
~MyException ();
const char *what () const;
private:
char *msg;
};
</pre>
</div>
<p>... you can define this python class, which may be raised as an exception:</p>
<div class="targetlang">
<pre>
class MyPyException (Exception, MyException) :
def __init__(self, msg, *args) :
Exception.__init__(self, *args)
self.myexc = MyException(msg)
def what (self) :
return self.myexc.what()
</pre>
</div>
</li>
<li><p>Reverse binary operators (e.g., <tt>__radd__</tt>) are not supported.</p></li>
</ul>
</p>