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

Add C++17 documentation chapter

Browse source
This commit is contained in:
William S Fulton 2018-05-14 21:23:27 +01:00
commit 066c396ad6
39 changed files with 1131 additions and 1112 deletions
Download patch file Download diff file Expand all files Collapse all files

192
Doc/Manual/Python.html
View file

@ -7,7 +7,7 @@
</head>
<body bgcolor="#ffffff">
<H1><a name="Python">36 SWIG and Python</a></H1>
<H1><a name="Python">37 SWIG and Python</a></H1>
<!-- INDEX -->
<div class="sectiontoc">
<ul>
@ -162,7 +162,7 @@ very least, make sure you read the "<a href="SWIG.html#SWIG">SWIG
Basics</a>" chapter.
</p>
<H2><a name="Python_nn2">36.1 Overview</a></H2>
<H2><a name="Python_nn2">37.1 Overview</a></H2>
<p>
@ -189,10 +189,10 @@ described followed by a discussion of low-level implementation
details.
</p>
<H2><a name="Python_nn3">36.2 Preliminaries</a></H2>
<H2><a name="Python_nn3">37.2 Preliminaries</a></H2>
<H3><a name="Python_nn4">36.2.1 Running SWIG</a></H3>
<H3><a name="Python_nn4">37.2.1 Running SWIG</a></H3>
<p>
@ -289,7 +289,7 @@ The following sections have further practical examples and details on
how you might go about compiling and using the generated files.
</p>
<H3><a name="Python_nn6">36.2.2 Using distutils</a></H3>
<H3><a name="Python_nn6">37.2.2 Using distutils</a></H3>
<p>
@ -381,7 +381,7 @@ This same approach works on all platforms if the appropriate compiler is install
can even build extensions to the standard Windows Python using MingGW)
</p>
<H3><a name="Python_nn7">36.2.3 Hand compiling a dynamic module</a></H3>
<H3><a name="Python_nn7">37.2.3 Hand compiling a dynamic module</a></H3>
<p>
@ -429,7 +429,7 @@ module actually consists of two files; <tt>socket.py</tt> and
</p>
<H3><a name="Python_nn8">36.2.4 Static linking</a></H3>
<H3><a name="Python_nn8">37.2.4 Static linking</a></H3>
<p>
@ -508,7 +508,7 @@ If using static linking, you might want to rely on a different approach
(perhaps using distutils).
</p>
<H3><a name="Python_nn9">36.2.5 Using your module</a></H3>
<H3><a name="Python_nn9">37.2.5 Using your module</a></H3>
<p>
@ -665,7 +665,7 @@ system configuration (this requires root access and you will need to
read the man pages).
</p>
<H3><a name="Python_nn10">36.2.6 Compilation of C++ extensions</a></H3>
<H3><a name="Python_nn10">37.2.6 Compilation of C++ extensions</a></H3>
<p>
@ -757,7 +757,7 @@ erratic program behavior. If working with lots of software components, you
might want to investigate using a more formal standard such as COM.
</p>
<H3><a name="Python_nn11">36.2.7 Compiling for 64-bit platforms</a></H3>
<H3><a name="Python_nn11">37.2.7 Compiling for 64-bit platforms</a></H3>
<p>
@ -794,7 +794,7 @@ and -m64 allow you to choose the desired binary format for your python
extension.
</p>
<H3><a name="Python_nn12">36.2.8 Building Python Extensions under Windows</a></H3>
<H3><a name="Python_nn12">37.2.8 Building Python Extensions under Windows</a></H3>
<p>
@ -923,7 +923,7 @@ SWIG Wiki</a>.
</p>
<H2><a name="Python_nn13">36.3 A tour of basic C/C++ wrapping</a></H2>
<H2><a name="Python_nn13">37.3 A tour of basic C/C++ wrapping</a></H2>
<p>
@ -932,7 +932,7 @@ to your C/C++ code. Functions are wrapped as functions, classes are wrapped as
This section briefly covers the essential aspects of this wrapping.
</p>
<H3><a name="Python_nn14">36.3.1 Modules</a></H3>
<H3><a name="Python_nn14">37.3.1 Modules</a></H3>
<p>
@ -945,7 +945,7 @@ module name, make sure you don't use the same name as a built-in
Python command or standard module name.
</p>
<H3><a name="Python_nn15">36.3.2 Functions</a></H3>
<H3><a name="Python_nn15">37.3.2 Functions</a></H3>
<p>
@ -969,7 +969,7 @@ like you think it does:
&gt;&gt;&gt;
</pre></div>
<H3><a name="Python_nn16">36.3.3 Global variables</a></H3>
<H3><a name="Python_nn16">37.3.3 Global variables</a></H3>
<p>
@ -1107,7 +1107,7 @@ that starts with a leading underscore. SWIG does not create <tt>cvar</tt>
if there are no global variables in a module.
</p>
<H3><a name="Python_nn17">36.3.4 Constants and enums</a></H3>
<H3><a name="Python_nn17">37.3.4 Constants and enums</a></H3>
<p>
@ -1147,7 +1147,7 @@ other object. Unfortunately, there is no easy way for SWIG to
generate code that prevents this. You will just have to be careful.
</p>
<H3><a name="Python_nn18">36.3.5 Pointers</a></H3>
<H3><a name="Python_nn18">37.3.5 Pointers</a></H3>
<p>
@ -1288,7 +1288,7 @@ C-style cast may return a bogus result whereas as the C++-style cast will return
<tt>None</tt> if the conversion can't be performed.
</p>
<H3><a name="Python_nn19">36.3.6 Structures</a></H3>
<H3><a name="Python_nn19">37.3.6 Structures</a></H3>
<p>
@ -1477,7 +1477,7 @@ everything works just like you would expect. For example:
</pre>
</div>
<H3><a name="Python_nn20">36.3.7 C++ classes</a></H3>
<H3><a name="Python_nn20">37.3.7 C++ classes</a></H3>
<p>
@ -1565,7 +1565,7 @@ they are accessed through <tt>cvar</tt> like this:
</pre>
</div>
<H3><a name="Python_nn21">36.3.8 C++ inheritance</a></H3>
<H3><a name="Python_nn21">37.3.8 C++ inheritance</a></H3>
<p>
@ -1620,7 +1620,7 @@ then the function <tt>spam()</tt> accepts <tt>Foo *</tt> or a pointer to any cla
It is safe to use multiple inheritance with SWIG.
</p>
<H3><a name="Python_nn22">36.3.9 Pointers, references, values, and arrays</a></H3>
<H3><a name="Python_nn22">37.3.9 Pointers, references, values, and arrays</a></H3>
<p>
@ -1681,7 +1681,7 @@ treated as a returning value, and it will follow the same
allocation/deallocation process.
</p>
<H3><a name="Python_nn23">36.3.10 C++ overloaded functions</a></H3>
<H3><a name="Python_nn23">37.3.10 C++ overloaded functions</a></H3>
<p>
@ -1804,7 +1804,7 @@ first declaration takes precedence.
Please refer to the "SWIG and C++" chapter for more information about overloading.
</p>
<H3><a name="Python_nn24">36.3.11 C++ operators</a></H3>
<H3><a name="Python_nn24">37.3.11 C++ operators</a></H3>
<p>
@ -1901,7 +1901,7 @@ instead of raising an exception when the comparison fails, that is, on any kind
This follows the guidelines in <a href="https://www.python.org/dev/peps/pep-0207/">PEP 207 - Rich Comparisons</a> and <a href="https://docs.python.org/3/library/constants.html#NotImplemented">NotImplemented Python constant</a>.
</p>
<H3><a name="Python_nn25">36.3.12 C++ namespaces</a></H3>
<H3><a name="Python_nn25">37.3.12 C++ namespaces</a></H3>
<p>
@ -1968,7 +1968,7 @@ utilizes thousands of small deeply nested namespaces each with
identical symbol names, well, then you get what you deserve.
</p>
<H3><a name="Python_nn26">36.3.13 C++ templates</a></H3>
<H3><a name="Python_nn26">37.3.13 C++ templates</a></H3>
<p>
@ -2022,10 +2022,10 @@ Some more complicated
examples will appear later.
</p>
<H3><a name="Python_nn27">36.3.14 C++ Smart Pointers</a></H3>
<H3><a name="Python_nn27">37.3.14 C++ Smart Pointers</a></H3>
<H4><a name="Python_smart_pointers_shared_ptr">36.3.14.1 The shared_ptr Smart Pointer</a></H4>
<H4><a name="Python_smart_pointers_shared_ptr">37.3.14.1 The shared_ptr Smart Pointer</a></H4>
<p>
@ -2036,7 +2036,7 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
</p>
<H4><a name="Python_smart_pointers_generic">36.3.14.2 Generic Smart Pointers</a></H4>
<H4><a name="Python_smart_pointers_generic">37.3.14.2 Generic Smart Pointers</a></H4>
<p>
@ -2120,7 +2120,7 @@ simply use the <tt>__deref__()</tt> method. For example:
</pre>
</div>
<H3><a name="Python_nn27a">36.3.15 C++ reference counted objects</a></H3>
<H3><a name="Python_nn27a">37.3.15 C++ reference counted objects</a></H3>
<p>
@ -2129,7 +2129,7 @@ Python examples of memory management using referencing counting.
</p>
<H2><a name="Python_nn28">36.4 Further details on the Python class interface</a></H2>
<H2><a name="Python_nn28">37.4 Further details on the Python class interface</a></H2>
<p>
@ -2152,7 +2152,7 @@ the <tt>-builtin</tt> option are in the <a href="#Python_builtin_types">Built-in
section.
</p>
<H3><a name="Python_nn29">36.4.1 Proxy classes</a></H3>
<H3><a name="Python_nn29">37.4.1 Proxy classes</a></H3>
<p>
@ -2241,7 +2241,7 @@ you can attach new Python methods to the class and you can even inherit from it
by Python built-in types until Python 2.2).
</p>
<H3><a name="Python_builtin_types">36.4.2 Built-in Types</a></H3>
<H3><a name="Python_builtin_types">37.4.2 Built-in Types</a></H3>
<p>
@ -2285,7 +2285,7 @@ please refer to the python documentation:</p>
<p><a href="http://docs.python.org/extending/newtypes.html">http://docs.python.org/extending/newtypes.html</a></p>
<H4><a name="Python_builtin_limitations">36.4.2.1 Limitations</a></H4>
<H4><a name="Python_builtin_limitations">37.4.2.1 Limitations</a></H4>
<p>Use of the <tt>-builtin</tt> option implies a couple of limitations:
@ -2453,7 +2453,7 @@ assert(issubclass(B.Derived, A.Base))
</li>
</ul>
<H4><a name="Python_builtin_overloads">36.4.2.2 Operator overloads and slots -- use them!</a></H4>
<H4><a name="Python_builtin_overloads">37.4.2.2 Operator overloads and slots -- use them!</a></H4>
<p>The entire justification for the <tt>-builtin</tt> option is improved
@ -2613,7 +2613,7 @@ in the file <tt>python/pyopers.swig</tt> in the SWIG library.
</p>
<H3><a name="Python_nn30">36.4.3 Memory management</a></H3>
<H3><a name="Python_nn30">37.4.3 Memory management</a></H3>
<p>NOTE: Although this section refers to proxy objects, everything here also applies
@ -2808,7 +2808,7 @@ It is also possible to deal with situations like this using
typemaps--an advanced topic discussed later.
</p>
<H3><a name="Python_nn31">36.4.4 Python 2.2 and classic classes</a></H3>
<H3><a name="Python_nn31">37.4.4 Python 2.2 and classic classes</a></H3>
<p>
@ -2845,7 +2845,7 @@ class itself. In Python-2.1 and earlier, they have to be accessed as a global
function or through an instance (see the earlier section).
</p>
<H2><a name="Python_directors">36.5 Cross language polymorphism</a></H2>
<H2><a name="Python_directors">37.5 Cross language polymorphism</a></H2>
<p>
@ -2879,7 +2879,7 @@ proxy classes, director classes, and C wrapper functions takes care of
all the cross-language method routing transparently.
</p>
<H3><a name="Python_nn33">36.5.1 Enabling directors</a></H3>
<H3><a name="Python_nn33">37.5.1 Enabling directors</a></H3>
<p>
@ -2971,7 +2971,7 @@ class MyFoo(mymodule.Foo):
</div>
<H3><a name="Python_nn34">36.5.2 Director classes</a></H3>
<H3><a name="Python_nn34">37.5.2 Director classes</a></H3>
<p>
@ -3050,7 +3050,7 @@ so there is no need for the extra overhead involved with routing the
calls through Python.
</p>
<H3><a name="Python_nn35">36.5.3 Ownership and object destruction</a></H3>
<H3><a name="Python_nn35">37.5.3 Ownership and object destruction</a></H3>
<p>
@ -3117,7 +3117,7 @@ deleting all the Foo pointers it contains at some point. Note that no hard
references to the Foo objects remain in Python.
</p>
<H3><a name="Python_nn36">36.5.4 Exception unrolling</a></H3>
<H3><a name="Python_nn36">37.5.4 Exception unrolling</a></H3>
<p>
@ -3176,7 +3176,7 @@ Swig::DirectorMethodException is thrown, Python will register the
exception as soon as the C wrapper function returns.
</p>
<H3><a name="Python_nn37">36.5.5 Overhead and code bloat</a></H3>
<H3><a name="Python_nn37">37.5.5 Overhead and code bloat</a></H3>
<p>
@ -3210,7 +3210,7 @@ directive) for only those methods that are likely to be extended in
Python.
</p>
<H3><a name="Python_nn38">36.5.6 Typemaps</a></H3>
<H3><a name="Python_nn38">37.5.6 Typemaps</a></H3>
<p>
@ -3224,7 +3224,7 @@ need to be supported.
</p>
<H3><a name="Python_nn39">36.5.7 Miscellaneous</a></H3>
<H3><a name="Python_nn39">37.5.7 Miscellaneous</a></H3>
<p>
@ -3271,7 +3271,7 @@ methods that return const references.
</p>
<H2><a name="Python_nn40">36.6 Common customization features</a></H2>
<H2><a name="Python_nn40">37.6 Common customization features</a></H2>
<p>
@ -3284,7 +3284,7 @@ This section describes some common SWIG features that are used to
improve your the interface to an extension module.
</p>
<H3><a name="Python_nn41">36.6.1 C/C++ helper functions</a></H3>
<H3><a name="Python_nn41">37.6.1 C/C++ helper functions</a></H3>
<p>
@ -3365,7 +3365,7 @@ hard to implement. It is possible to clean this up using Python code, typemaps,
customization features as covered in later sections.
</p>
<H3><a name="Python_nn42">36.6.2 Adding additional Python code</a></H3>
<H3><a name="Python_nn42">37.6.2 Adding additional Python code</a></H3>
<p>
@ -3617,7 +3617,7 @@ The same applies for overloaded constructors.
</p>
<H3><a name="Python_nn43">36.6.3 Class extension with %extend</a></H3>
<H3><a name="Python_nn43">37.6.3 Class extension with %extend</a></H3>
<p>
@ -3706,7 +3706,7 @@ Vector(12, 14, 16)
in any way---the extensions only show up in the Python interface.
</p>
<H3><a name="Python_nn44">36.6.4 Exception handling with %exception</a></H3>
<H3><a name="Python_nn44">37.6.4 Exception handling with %exception</a></H3>
<p>
@ -3840,7 +3840,7 @@ The language-independent <tt>exception.i</tt> library file can also be used
to raise exceptions. See the <a href="Library.html#Library">SWIG Library</a> chapter.
</p>
<H2><a name="Python_nn45">36.7 Tips and techniques</a></H2>
<H2><a name="Python_nn45">37.7 Tips and techniques</a></H2>
<p>
@ -3850,7 +3850,7 @@ strings, binary data, and arrays. This chapter discusses the common techniques
solving these problems.
</p>
<H3><a name="Python_nn46">36.7.1 Input and output parameters</a></H3>
<H3><a name="Python_nn46">37.7.1 Input and output parameters</a></H3>
<p>
@ -4063,7 +4063,7 @@ void foo(Bar *OUTPUT);
may not have the intended effect since <tt>typemaps.i</tt> does not define an OUTPUT rule for <tt>Bar</tt>.
</p>
<H3><a name="Python_nn47">36.7.2 Simple pointers</a></H3>
<H3><a name="Python_nn47">37.7.2 Simple pointers</a></H3>
<p>
@ -4132,7 +4132,7 @@ If you replace <tt>%pointer_functions()</tt> by <tt>%pointer_class(type, name)</
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
</p>
<H3><a name="Python_nn48">36.7.3 Unbounded C Arrays</a></H3>
<H3><a name="Python_nn48">37.7.3 Unbounded C Arrays</a></H3>
<p>
@ -4194,7 +4194,7 @@ well suited for applications in which you need to create buffers,
package binary data, etc.
</p>
<H3><a name="Python_nn49">36.7.4 String handling</a></H3>
<H3><a name="Python_nn49">37.7.4 String handling</a></H3>
<p>
@ -4264,7 +4264,7 @@ also be used to extra binary data from arbitrary pointers.
</p>
<H3><a name="Python_default_args">36.7.5 Default arguments</a></H3>
<H3><a name="Python_default_args">37.7.5 Default arguments</a></H3>
<p>
@ -4363,7 +4363,7 @@ Versions of SWIG prior to this varied in their ability to convert C++ default va
equivalent Python default argument values.
</p>
<H2><a name="Python_nn53">36.8 Typemaps</a></H2>
<H2><a name="Python_nn53">37.8 Typemaps</a></H2>
<p>
@ -4380,7 +4380,7 @@ Typemaps are only used if you want to change some aspect of the primitive
C-Python interface or if you want to elevate your guru status.
</p>
<H3><a name="Python_nn54">36.8.1 What is a typemap?</a></H3>
<H3><a name="Python_nn54">37.8.1 What is a typemap?</a></H3>
<p>
@ -4496,7 +4496,7 @@ parameter is omitted):
</pre>
</div>
<H3><a name="Python_nn55">36.8.2 Python typemaps</a></H3>
<H3><a name="Python_nn55">37.8.2 Python typemaps</a></H3>
<p>
@ -4537,7 +4537,7 @@ a look at the SWIG library version 1.3.20 or so.
</p>
<H3><a name="Python_nn56">36.8.3 Typemap variables</a></H3>
<H3><a name="Python_nn56">37.8.3 Typemap variables</a></H3>
<p>
@ -4608,7 +4608,7 @@ properly assigned.
The Python name of the wrapper function being created.
</div>
<H3><a name="Python_nn57">36.8.4 Useful Python Functions</a></H3>
<H3><a name="Python_nn57">37.8.4 Useful Python Functions</a></H3>
<p>
@ -4736,7 +4736,7 @@ write me
</pre>
</div>
<H2><a name="Python_nn58">36.9 Typemap Examples</a></H2>
<H2><a name="Python_nn58">37.9 Typemap Examples</a></H2>
<p>
@ -4745,7 +4745,7 @@ might look at the files "<tt>python.swg</tt>" and "<tt>typemaps.i</tt>" in
the SWIG library.
</p>
<H3><a name="Python_nn59">36.9.1 Converting Python list to a char ** </a></H3>
<H3><a name="Python_nn59">37.9.1 Converting Python list to a char ** </a></H3>
<p>
@ -4825,7 +4825,7 @@ memory allocation is used to allocate memory for the array, the
the C function.
</p>
<H3><a name="Python_nn60">36.9.2 Expanding a Python object into multiple arguments</a></H3>
<H3><a name="Python_nn60">37.9.2 Expanding a Python object into multiple arguments</a></H3>
<p>
@ -4944,7 +4944,7 @@ NotImplementedError: Wrong number or type of arguments for overloaded function '
</pre>
</div>
<H3><a name="Python_nn61">36.9.3 Using typemaps to return arguments</a></H3>
<H3><a name="Python_nn61">37.9.3 Using typemaps to return arguments</a></H3>
<p>
@ -5032,7 +5032,7 @@ function can now be used as follows:
&gt;&gt;&gt;
</pre></div>
<H3><a name="Python_nn62">36.9.4 Mapping Python tuples into small arrays</a></H3>
<H3><a name="Python_nn62">37.9.4 Mapping Python tuples into small arrays</a></H3>
<p>
@ -5081,7 +5081,7 @@ array, such an approach would not be recommended for huge arrays, but
for small structures, this approach works fine.
</p>
<H3><a name="Python_nn63">36.9.5 Mapping sequences to C arrays</a></H3>
<H3><a name="Python_nn63">37.9.5 Mapping sequences to C arrays</a></H3>
<p>
@ -5170,7 +5170,7 @@ static int convert_darray(PyObject *input, double *ptr, int size) {
</pre>
</div>
<H3><a name="Python_nn64">36.9.6 Pointer handling</a></H3>
<H3><a name="Python_nn64">37.9.6 Pointer handling</a></H3>
<p>
@ -5269,7 +5269,7 @@ class object (if applicable).
<H2><a name="Python_nn65">36.10 Docstring Features</a></H2>
<H2><a name="Python_nn65">37.10 Docstring Features</a></H2>
<p>
@ -5297,7 +5297,7 @@ of your users much simpler.
</p>
<H3><a name="Python_nn66">36.10.1 Module docstring</a></H3>
<H3><a name="Python_nn66">37.10.1 Module docstring</a></H3>
<p>
@ -5331,7 +5331,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
</div>
<H3><a name="Python_nn67">36.10.2 %feature("autodoc")</a></H3>
<H3><a name="Python_nn67">37.10.2 %feature("autodoc")</a></H3>
<p>
@ -5359,7 +5359,7 @@ four levels for autodoc controlled by the value given to the
feature, <tt>%feature("autodoc", "<i>level</i>")</tt>.
The four values for <i>level</i> are covered in the following sub-sections.
<H4><a name="Python_nn68">36.10.2.1 %feature("autodoc", "0")</a></H4>
<H4><a name="Python_nn68">37.10.2.1 %feature("autodoc", "0")</a></H4>
<p>
@ -5388,7 +5388,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_nn69">36.10.2.2 %feature("autodoc", "1")</a></H4>
<H4><a name="Python_nn69">37.10.2.2 %feature("autodoc", "1")</a></H4>
<p>
@ -5413,7 +5413,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_autodoc2">36.10.2.3 %feature("autodoc", "2")</a></H4>
<H4><a name="Python_autodoc2">37.10.2.3 %feature("autodoc", "2")</a></H4>
<p>
@ -5475,7 +5475,7 @@ def function_name(*args, **kwargs):
</pre>
</div>
<H4><a name="Python_autodoc3">36.10.2.4 %feature("autodoc", "3")</a></H4>
<H4><a name="Python_autodoc3">37.10.2.4 %feature("autodoc", "3")</a></H4>
<p>
@ -5501,7 +5501,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_nn70">36.10.2.5 %feature("autodoc", "docstring")</a></H4>
<H4><a name="Python_nn70">37.10.2.5 %feature("autodoc", "docstring")</a></H4>
<p>
@ -5520,7 +5520,7 @@ void GetPosition(int* OUTPUT, int* OUTPUT);
</div>
<H3><a name="Python_nn71">36.10.3 %feature("docstring")</a></H3>
<H3><a name="Python_nn71">37.10.3 %feature("docstring")</a></H3>
<p>
@ -5552,7 +5552,7 @@ with more than one line.
</pre>
</div>
<H2><a name="Python_nn72">36.11 Python Packages</a></H2>
<H2><a name="Python_nn72">37.11 Python Packages</a></H2>
<p>Python has concepts of modules and packages. Modules are separate units of
@ -5627,7 +5627,7 @@ users may need to use special features such as the <tt>package</tt> option in th
<tt>%module</tt> directive or import related command line options. These are
explained in the following sections.</p>
<H3><a name="Python_modulepackage">36.11.1 Setting the Python package</a></H3>
<H3><a name="Python_modulepackage">37.11.1 Setting the Python package</a></H3>
<p>
@ -5681,7 +5681,7 @@ pkg1/pkg2/_foo.so # (shared library built from C/C++ code generated by SWI
</pre>
</div>
<H3><a name="Python_absrelimports">36.11.2 Absolute and relative imports</a></H3>
<H3><a name="Python_absrelimports">37.11.2 Absolute and relative imports</a></H3>
<p>Suppose, we have the following hierarchy of files:</p>
@ -5816,7 +5816,7 @@ uses relative imports. Second case is, when one puts import directives in
<tt>__init__.py</tt> to import symbols from submodules or subpackages and the
submodule depends on other submodules (discussed later).</p>
<H3><a name="Python_absimport">36.11.3 Enforcing absolute import semantics</a></H3>
<H3><a name="Python_absimport">37.11.3 Enforcing absolute import semantics</a></H3>
<p>As you may know, there is an incompatibility in import semantics (for the
@ -5853,7 +5853,7 @@ from __future__ import absolute_import
</pre>
</div>
<H3><a name="Python_importfrominit">36.11.4 Importing from __init__.py</a></H3>
<H3><a name="Python_importfrominit">37.11.4 Importing from __init__.py</a></H3>
<p>Imports in <tt>__init__.py</tt> are handy when you want to populate a
@ -5963,7 +5963,7 @@ class Bar(pkg3.foo.Foo): pass
effect (note, that the Python 2 case also needs the <tt>-relativeimport</tt>
workaround).</p>
<H3><a name="Python_implicit_namespace_packages">36.11.5 Implicit Namespace Packages</a></H3>
<H3><a name="Python_implicit_namespace_packages">37.11.5 Implicit Namespace Packages</a></H3>
<p> Python 3.3 introduced
@ -6041,7 +6041,7 @@ zipimporter requires python-3.5.1 or newer to work with subpackages.
</p>
<H3><a name="Python_package_search">36.11.6 Searching for the wrapper module</a></H3>
<H3><a name="Python_package_search">37.11.6 Searching for the wrapper module</a></H3>
<p>
@ -6116,7 +6116,7 @@ following ways:
</p>
<H4><a name="Python_package_search_both_package_modules">36.11.6.1 Both modules in the same package</a></H4>
<H4><a name="Python_package_search_both_package_modules">37.11.6.1 Both modules in the same package</a></H4>
<p>Both modules are in one package:</p>
@ -6135,7 +6135,7 @@ from package import foo
</div>
<H4><a name="Python_package_search_wrapper_split">36.11.6.2 Split modules</a></H4>
<H4><a name="Python_package_search_wrapper_split">37.11.6.2 Split modules</a></H4>
<p>The pure python module is in a package and the C/C++ module is global:</p>
@ -6154,7 +6154,7 @@ from package import foo
</div>
<H4><a name="Python_package_search_both_global_modules">36.11.6.3 Both modules are global</a></H4>
<H4><a name="Python_package_search_both_global_modules">37.11.6.3 Both modules are global</a></H4>
<p>Both modules are global:</p>
@ -6179,7 +6179,7 @@ loaded modules. So, one may place the module either globally or in a package
as desired.
</p>
<H4><a name="Python_package_search_static">36.11.6.4 Statically linked C modules</a></H4>
<H4><a name="Python_package_search_static">37.11.6.4 Statically linked C modules</a></H4>
<p>It is strongly recommended to use dynamically linked modules for the C
@ -6251,7 +6251,7 @@ module then you will either need to refer to the Python documentation on how
to do this (remember you are now the Python importer) or use dynamic linking.
</p>
<H2><a name="Python_python3support">36.12 Python 3 Support</a></H2>
<H2><a name="Python_python3support">37.12 Python 3 Support</a></H2>
<p>
@ -6278,7 +6278,7 @@ The following are Python 3.0 new features that are currently supported by
SWIG.
</p>
<H3><a name="Python_nn74">36.12.1 Function annotation</a></H3>
<H3><a name="Python_nn74">37.12.1 Function annotation</a></H3>
<p>
@ -6311,7 +6311,7 @@ For detailed usage of function annotation, see
<a href="https://www.python.org/dev/peps/pep-3107/">PEP 3107</a>.
</p>
<H3><a name="Python_nn75">36.12.2 Buffer interface</a></H3>
<H3><a name="Python_nn75">37.12.2 Buffer interface</a></H3>
<p>
@ -6463,7 +6463,7 @@ modify the buffer.
</div>
<H3><a name="Python_nn76">36.12.3 Abstract base classes</a></H3>
<H3><a name="Python_nn76">37.12.3 Abstract base classes</a></H3>
<p>
@ -6504,7 +6504,7 @@ For details of abstract base class, please see
<a href="https://www.python.org/dev/peps/pep-3119/">PEP 3119</a>.
</p>
<H3><a name="Python_nn77">36.12.4 Byte string output conversion</a></H3>
<H3><a name="Python_nn77">37.12.4 Byte string output conversion</a></H3>
<p>
@ -6684,7 +6684,7 @@ overloads taking both std::string (as Python bytes) and std::wstring
(as Python unicode).
</p>
<H3><a name="Python_2_unicode">36.12.5 Python 2 Unicode</a></H3>
<H3><a name="Python_2_unicode">37.12.5 Python 2 Unicode</a></H3>
<p>
@ -6756,7 +6756,7 @@ the first is allowing unicode conversion and the second is explicitly
prohibiting it.
</p>
<H2><a name="Python_multithreaded">36.13 Support for Multithreaded Applications</a></H2>
<H2><a name="Python_multithreaded">37.13 Support for Multithreaded Applications</a></H2>
<p>By default, SWIG does not enable support for multithreaded Python applications. More
@ -6771,7 +6771,7 @@ will not be able to run any other threads, even if the wrapped C/C++ code is wai
interface for this is described in the next section.
</p>
<H3><a name="Python_thread_UI">36.13.1 UI for Enabling Multithreading Support</a></H3>
<H3><a name="Python_thread_UI">37.13.1 UI for Enabling Multithreading Support</a></H3>
<p>The user interface is as follows:</p>
@ -6814,7 +6814,7 @@ will not be able to run any other threads, even if the wrapped C/C++ code is wai
</li>
</ol>
<H3><a name="Python_thread_performance">36.13.2 Multithread Performance</a></H3>
<H3><a name="Python_thread_performance">37.13.2 Multithread Performance</a></H3>
<p>