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

Merge branch 'vadz-doxygen'

Browse source 
This is the Doxygen work begun in Google Summer of Code projects 2008
and 2012 and subsequently improved by numerous contributors.

* vadz-doxygen: (314 commits)
  Add changes entry for Doxygen support
  Add some missing doctype tyemaps
  Doxygen warnings cleanup
  Move doxygen warning numbers
  Add Python doxygen example
  Doxygen example
  Add Doxygen to include paths
  Doxygen source rename
  More merge fixes from doxygen branches
  Correct python example headers
  Correct source code headers
  Another merge fix from doxygen branches
  Java enums output format fixes
  Add omitted doxygen_parsing_enums testcase
  PEP8 conformance for comment verifier module
  Clean up merge problem
  Doxygen html tweaks
  Update html chapter numbering for added Doxygen chapter
  Fixes to makechap.py to detect ill-formed headers
  html fixes for Doxygen
  Add missing CPlusPlus17.html file
  Format files to unix format
  Doxygen testcase tweak to match that in the html docs
  Doxygen html documentation updates and corrections
  Remove doxygen Examples subdirectory
  Beautify doxygen source code
  Code formatting fixes in doxygen code
  Remove unused doxygen code
  new_node refactor
  Various merge fixes in doxygen branches
  Unused variable warning fix
  Fix wrongly resetting indent after formulae in Doxygen comments
  Add support for doxygen:alias feature
  Get rid of meaningless return type of DoxygenParser methods
  Return enum, not untyped int, when classifying Doxygen commands
  Get rid of unnecessary "typedef enum" in C++ code
  Use slash, not backslash, in "C/C++" in the documentation
  Replace literal "<" with "&lt;" in HTML documentation
  Fix broken link to java.sun.com in Doxygen documentation
  Fix using com.sun.tools.javadoc package under macOS
  Fix error reporting for special characters in Doxygen parsing code
  Switch Python Doxygen unit tests to use inspect.getdoc()
  Use correct separator in Java class path under Windows.
  Remove executable permission from appveyor.yml.
  Use JAVA_HOME value in configure to detect Java.
  Display JAVA_HOME value in "make java_version".
  Fix harmless MSVC warning in DoxygenTranslator code.
  Reset "_last" for all but first enum elements.
  Don't duplicate Javadoc from global enum Doxygen comments twice.
  Move Doxygen comments concatenation from the parser to the lexer.
  Fix shift/reduce conflicts in Doxygen pre/post comment parsing.
  Rewrote part of the grammar dealing with Doxygen comments for enums.
  No changes, just remove spurious white space only differences.
  Move Doxygen comment mangling from the parser to the lexer.
  Merge "-builtin" autodoc bugs workarounds from master into test.
  Quote JAVA_HOME variable value in Java test suite makefile.
  Remove unused C_COMMENT_STRING terminal from the grammar.
  Fix missing returns in the Doxygen test suite code.
  Fix trimming whitespace from Doxygen comments.
  Remove code not doing anything from PyDocConverter.
  Remove unused <sstream> header.
  Remove unreferenced struct declaration.
  Remove unused Swig_warn() function.
  Remove any whitespace before ignored Doxygen commands.
  Remove trailing space from one of Doxygen tests.
  Fix autodoc strings generated in Python builtin case and the test.
  Fix Doxygen unit test in Python "-builtin" case.
  Use class docstrings in "-builtin" Python case.
  Don't indent Doxygen doc strings in generated Python code.
  Add a possibility to flexibly ignore custom Doxygen tags.
  Stop completely ignoring many Doxygen comments.
  Fix structural Doxygen comment recognition in the parser.
  No changes, just make checking for Doxygen structural tags more sane.
  Use "//", not "#", for comments in SWIG input.
  Allow upper case letters and digits in Doxygen words.
  Pass the node the Doxygen comment is attached to to DoxygenParser.
  Get rid of findCommand() which duplicaed commandBelongs().
  Recognize unknown Doxygen tags correctly.
  No real changes, just pass original command to commandBelongs().
  Describe Doxygen-specific %features in a single place.
  Give warnings for unknown Doxygen commands in Doxygen parser.
  Document the return type when translating Doxygen @return to Python.
  Fix translated Doxygen comments for overloaded functions in Python.
  Also merge Doxygen comments for overloaded constructors in Python.
  Allow using enum elements as default values for Python functions.
  Don't always use "*args" for all Python wrapper functions.
  No real changes, just make PYTHON::check_kwargs() const.
  Refactor: move makeParameterName() to common Language base class.
  Remove long line wrapping from Python parameter list generation code.
  Simplify and make more efficient building Python docstrings.
  Translate Doxygen code blocks to Sphinx code blocks.
  Add a simple test of multiple parameters to Doxygen test suite.
  Make Python parameters types hyperlinks in the doc strings.
  Make Language::classLookup() and enumLookup() static.
  Fix arguments of @param, @return etc translations to Python.
  Remove unused method from PyDocConverter.
  No real changes, just remove an unnecessary variable.
  Preserve relative indentation when parsing Doxygen comments.
  Use Sphinx-friendly formatting for overloaded functions documentation.
  Add poor man trailing white space detection to Doxygen Python tests.
  ...
This commit is contained in:
William S Fulton 2018-06-07 08:13:10 +01:00
commit 33921666a1
123 changed files with 12964 additions and 1344 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">37 SWIG and Python</a></H1>
<H1><a name="Python">38 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">37.1 Overview</a></H2>
<H2><a name="Python_nn2">38.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">37.2 Preliminaries</a></H2>
<H2><a name="Python_nn3">38.2 Preliminaries</a></H2>
<H3><a name="Python_nn4">37.2.1 Running SWIG</a></H3>
<H3><a name="Python_nn4">38.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">37.2.2 Using distutils</a></H3>
<H3><a name="Python_nn6">38.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">37.2.3 Hand compiling a dynamic module</a></H3>
<H3><a name="Python_nn7">38.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">37.2.4 Static linking</a></H3>
<H3><a name="Python_nn8">38.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">37.2.5 Using your module</a></H3>
<H3><a name="Python_nn9">38.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">37.2.6 Compilation of C++ extensions</a></H3>
<H3><a name="Python_nn10">38.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">37.2.7 Compiling for 64-bit platforms</a></H3>
<H3><a name="Python_nn11">38.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">37.2.8 Building Python Extensions under Windows</a></H3>
<H3><a name="Python_nn12">38.2.8 Building Python Extensions under Windows</a></H3>
<p>
@ -923,7 +923,7 @@ SWIG Wiki</a>.
</p>
<H2><a name="Python_nn13">37.3 A tour of basic C/C++ wrapping</a></H2>
<H2><a name="Python_nn13">38.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">37.3.1 Modules</a></H3>
<H3><a name="Python_nn14">38.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">37.3.2 Functions</a></H3>
<H3><a name="Python_nn15">38.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">37.3.3 Global variables</a></H3>
<H3><a name="Python_nn16">38.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">37.3.4 Constants and enums</a></H3>
<H3><a name="Python_nn17">38.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">37.3.5 Pointers</a></H3>
<H3><a name="Python_nn18">38.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">37.3.6 Structures</a></H3>
<H3><a name="Python_nn19">38.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">37.3.7 C++ classes</a></H3>
<H3><a name="Python_nn20">38.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">37.3.8 C++ inheritance</a></H3>
<H3><a name="Python_nn21">38.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">37.3.9 Pointers, references, values, and arrays</a></H3>
<H3><a name="Python_nn22">38.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">37.3.10 C++ overloaded functions</a></H3>
<H3><a name="Python_nn23">38.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">37.3.11 C++ operators</a></H3>
<H3><a name="Python_nn24">38.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">37.3.12 C++ namespaces</a></H3>
<H3><a name="Python_nn25">38.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">37.3.13 C++ templates</a></H3>
<H3><a name="Python_nn26">38.3.13 C++ templates</a></H3>
<p>
@ -2022,10 +2022,10 @@ Some more complicated
examples will appear later.
</p>
<H3><a name="Python_nn27">37.3.14 C++ Smart Pointers</a></H3>
<H3><a name="Python_nn27">38.3.14 C++ Smart Pointers</a></H3>
<H4><a name="Python_smart_pointers_shared_ptr">37.3.14.1 The shared_ptr Smart Pointer</a></H4>
<H4><a name="Python_smart_pointers_shared_ptr">38.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">37.3.14.2 Generic Smart Pointers</a></H4>
<H4><a name="Python_smart_pointers_generic">38.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">37.3.15 C++ reference counted objects</a></H3>
<H3><a name="Python_nn27a">38.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">37.4 Further details on the Python class interface</a></H2>
<H2><a name="Python_nn28">38.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">37.4.1 Proxy classes</a></H3>
<H3><a name="Python_nn29">38.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">37.4.2 Built-in Types</a></H3>
<H3><a name="Python_builtin_types">38.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">37.4.2.1 Limitations</a></H4>
<H4><a name="Python_builtin_limitations">38.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">37.4.2.2 Operator overloads and slots -- use them!</a></H4>
<H4><a name="Python_builtin_overloads">38.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">37.4.3 Memory management</a></H3>
<H3><a name="Python_nn30">38.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">37.4.4 Python 2.2 and classic classes</a></H3>
<H3><a name="Python_nn31">38.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">37.5 Cross language polymorphism</a></H2>
<H2><a name="Python_directors">38.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">37.5.1 Enabling directors</a></H3>
<H3><a name="Python_nn33">38.5.1 Enabling directors</a></H3>
<p>
@ -2971,7 +2971,7 @@ class MyFoo(mymodule.Foo):
</div>
<H3><a name="Python_nn34">37.5.2 Director classes</a></H3>
<H3><a name="Python_nn34">38.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">37.5.3 Ownership and object destruction</a></H3>
<H3><a name="Python_nn35">38.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">37.5.4 Exception unrolling</a></H3>
<H3><a name="Python_nn36">38.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">37.5.5 Overhead and code bloat</a></H3>
<H3><a name="Python_nn37">38.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">37.5.6 Typemaps</a></H3>
<H3><a name="Python_nn38">38.5.6 Typemaps</a></H3>
<p>
@ -3224,7 +3224,7 @@ need to be supported.
</p>
<H3><a name="Python_nn39">37.5.7 Miscellaneous</a></H3>
<H3><a name="Python_nn39">38.5.7 Miscellaneous</a></H3>
<p>
@ -3271,7 +3271,7 @@ methods that return const references.
</p>
<H2><a name="Python_nn40">37.6 Common customization features</a></H2>
<H2><a name="Python_nn40">38.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">37.6.1 C/C++ helper functions</a></H3>
<H3><a name="Python_nn41">38.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">37.6.2 Adding additional Python code</a></H3>
<H3><a name="Python_nn42">38.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">37.6.3 Class extension with %extend</a></H3>
<H3><a name="Python_nn43">38.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">37.6.4 Exception handling with %exception</a></H3>
<H3><a name="Python_nn44">38.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">37.7 Tips and techniques</a></H2>
<H2><a name="Python_nn45">38.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">37.7.1 Input and output parameters</a></H3>
<H3><a name="Python_nn46">38.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">37.7.2 Simple pointers</a></H3>
<H3><a name="Python_nn47">38.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">37.7.3 Unbounded C Arrays</a></H3>
<H3><a name="Python_nn48">38.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">37.7.4 String handling</a></H3>
<H3><a name="Python_nn49">38.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">37.7.5 Default arguments</a></H3>
<H3><a name="Python_default_args">38.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">37.8 Typemaps</a></H2>
<H2><a name="Python_nn53">38.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">37.8.1 What is a typemap?</a></H3>
<H3><a name="Python_nn54">38.8.1 What is a typemap?</a></H3>
<p>
@ -4496,7 +4496,7 @@ parameter is omitted):
</pre>
</div>
<H3><a name="Python_nn55">37.8.2 Python typemaps</a></H3>
<H3><a name="Python_nn55">38.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">37.8.3 Typemap variables</a></H3>
<H3><a name="Python_nn56">38.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">37.8.4 Useful Python Functions</a></H3>
<H3><a name="Python_nn57">38.8.4 Useful Python Functions</a></H3>
<p>
@ -4736,7 +4736,7 @@ write me
</pre>
</div>
<H2><a name="Python_nn58">37.9 Typemap Examples</a></H2>
<H2><a name="Python_nn58">38.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">37.9.1 Converting Python list to a char ** </a></H3>
<H3><a name="Python_nn59">38.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">37.9.2 Expanding a Python object into multiple arguments</a></H3>
<H3><a name="Python_nn60">38.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">37.9.3 Using typemaps to return arguments</a></H3>
<H3><a name="Python_nn61">38.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">37.9.4 Mapping Python tuples into small arrays</a></H3>
<H3><a name="Python_nn62">38.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">37.9.5 Mapping sequences to C arrays</a></H3>
<H3><a name="Python_nn63">38.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">37.9.6 Pointer handling</a></H3>
<H3><a name="Python_nn64">38.9.6 Pointer handling</a></H3>
<p>
@ -5269,7 +5269,7 @@ class object (if applicable).
<H2><a name="Python_nn65">37.10 Docstring Features</a></H2>
<H2><a name="Python_nn65">38.10 Docstring Features</a></H2>
<p>
@ -5297,7 +5297,7 @@ of your users much simpler.
</p>
<H3><a name="Python_nn66">37.10.1 Module docstring</a></H3>
<H3><a name="Python_nn66">38.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">37.10.2 %feature("autodoc")</a></H3>
<H3><a name="Python_nn67">38.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">37.10.2.1 %feature("autodoc", "0")</a></H4>
<H4><a name="Python_nn68">38.10.2.1 %feature("autodoc", "0")</a></H4>
<p>
@ -5388,7 +5388,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_nn69">37.10.2.2 %feature("autodoc", "1")</a></H4>
<H4><a name="Python_nn69">38.10.2.2 %feature("autodoc", "1")</a></H4>
<p>
@ -5413,7 +5413,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_autodoc2">37.10.2.3 %feature("autodoc", "2")</a></H4>
<H4><a name="Python_autodoc2">38.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">37.10.2.4 %feature("autodoc", "3")</a></H4>
<H4><a name="Python_autodoc3">38.10.2.4 %feature("autodoc", "3")</a></H4>
<p>
@ -5501,7 +5501,7 @@ def function_name(*args, **kwargs):
</div>
<H4><a name="Python_nn70">37.10.2.5 %feature("autodoc", "docstring")</a></H4>
<H4><a name="Python_nn70">38.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">37.10.3 %feature("docstring")</a></H3>
<H3><a name="Python_nn71">38.10.3 %feature("docstring")</a></H3>
<p>
@ -5552,7 +5552,7 @@ with more than one line.
</pre>
</div>
<H2><a name="Python_nn72">37.11 Python Packages</a></H2>
<H2><a name="Python_nn72">38.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">37.11.1 Setting the Python package</a></H3>
<H3><a name="Python_modulepackage">38.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">37.11.2 Absolute and relative imports</a></H3>
<H3><a name="Python_absrelimports">38.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">37.11.3 Enforcing absolute import semantics</a></H3>
<H3><a name="Python_absimport">38.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">37.11.4 Importing from __init__.py</a></H3>
<H3><a name="Python_importfrominit">38.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">37.11.5 Implicit Namespace Packages</a></H3>
<H3><a name="Python_implicit_namespace_packages">38.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">37.11.6 Searching for the wrapper module</a></H3>
<H3><a name="Python_package_search">38.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">37.11.6.1 Both modules in the same package</a></H4>
<H4><a name="Python_package_search_both_package_modules">38.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">37.11.6.2 Split modules</a></H4>
<H4><a name="Python_package_search_wrapper_split">38.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">37.11.6.3 Both modules are global</a></H4>
<H4><a name="Python_package_search_both_global_modules">38.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">37.11.6.4 Statically linked C modules</a></H4>
<H4><a name="Python_package_search_static">38.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">37.12 Python 3 Support</a></H2>
<H2><a name="Python_python3support">38.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">37.12.1 Function annotation</a></H3>
<H3><a name="Python_nn74">38.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">37.12.2 Buffer interface</a></H3>
<H3><a name="Python_nn75">38.12.2 Buffer interface</a></H3>
<p>
@ -6463,7 +6463,7 @@ modify the buffer.
</div>
<H3><a name="Python_nn76">37.12.3 Abstract base classes</a></H3>
<H3><a name="Python_nn76">38.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">37.12.4 Byte string output conversion</a></H3>
<H3><a name="Python_nn77">38.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">37.12.5 Python 2 Unicode</a></H3>
<H3><a name="Python_2_unicode">38.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">37.13 Support for Multithreaded Applications</a></H2>
<H2><a name="Python_multithreaded">38.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">37.13.1 UI for Enabling Multithreading Support</a></H3>
<H3><a name="Python_thread_UI">38.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">37.13.2 Multithread Performance</a></H3>
<H3><a name="Python_thread_performance">38.13.2 Multithread Performance</a></H3>
<p>