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

Update packages section in Python html docs

Browse source 
Updates given only Python 2.7, 3.2+ are now supported.
This commit is contained in:
William S Fulton 2018-12-08 20:25:58 +00:00
commit b19d3e06b3
1 changed files with 16 additions and 14 deletions
Download patch file Download diff file Expand all files Collapse all files

30
Doc/Manual/Python.html
View file

@ -5853,12 +5853,19 @@ class M2(pkg2.mod3.M3): pass
</pre>
</div>
<p>By default, SWIG would generate <tt>mod2.py</tt> proxy file with
<p>By default, SWIG will generate <tt>mod2.py</tt> proxy file with
<tt>import</tt> directive as in point 1. This can be changed with the
<tt>-relativeimport</tt> command line option. The <tt>-relativeimport</tt> instructs
SWIG to organize imports as in point 2 (for Python < 2.7.0) or as in point 4
for Python 2.7.0 and newer. This is a check done at the time the module is
imported. In short, if you have
SWIG to organize imports as in point 4 for Python 2.7.0 and newer.
</p>
<p>
<b>Compatibility Note:</b> Versions of SWIG prior to SWIG-4.0.0 supported Python &lt; 2.7.0
and would organize the imports as in point 2 if an older version of Python was detected at runtime.
</p>
<p>
In short, if you have
<tt>mod2.i</tt> and <tt>mod3.i</tt> as above, then without
<tt>-relativeimport</tt> SWIG will write</p>
@ -5873,13 +5880,8 @@ write</p>
<div class="targetlang">
<pre>
from sys import version_info
if version_info &gt;= (2, 7, 0):
from . import pkg2
import pkg1.pkg2.mod3
else:
import pkg2.mod3
del version_info
from . import pkg2
from .pkg2 import mod3
</pre>
</div>
@ -5917,7 +5919,7 @@ from __future__ import absolute_import
</pre>
</div>
<p>at the very beginning of his proxy <tt>*.py</tt> file. In SWIG, it may be
<p>at the very beginning of your proxy <tt>*.py</tt> file. In SWIG, it may be
accomplished with <tt>%pythonbegin</tt> directive as follows:</p>
<div class="code">
@ -6129,8 +6131,8 @@ covered next.
</p>
<p>
The pure Python module needs to load the C/C++ module in order to link
to the wrapped C/C++ methods. To do this it must make some assumptions
The pure Python module needs to load the C/C++ module in order to call
the wrapped C/C++ methods. To do this it must make some assumptions
about what package the C/C++ module may be located in. The approach the
pure Python module uses to find the C/C++ module is as follows:
</p>