Correct links in html documentation using new version of makechap.py
Corrects position of heading text within A and H1, H2, ... elements.
This commit is contained in:
parent
abe42bbb16
commit
8288ac15a0
41 changed files with 1262 additions and 1262 deletions
|
|
@ -6,7 +6,7 @@
|
|||
</head>
|
||||
|
||||
<body bgcolor="#ffffff">
|
||||
<H1><a name="Python"></a>36 SWIG and Python</H1>
|
||||
<H1><a name="Python">36 SWIG and Python</a></H1>
|
||||
<!-- INDEX -->
|
||||
<div class="sectiontoc">
|
||||
<ul>
|
||||
|
|
@ -148,7 +148,7 @@ very least, make sure you read the "<a href="SWIG.html#SWIG">SWIG
|
|||
Basics</a>" chapter.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn2"></a>36.1 Overview</H2>
|
||||
<H2><a name="Python_nn2">36.1 Overview</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -175,10 +175,10 @@ described followed by a discussion of low-level implementation
|
|||
details.
|
||||
</p>
|
||||
|
||||
<H2><a name="Python_nn3"></a>36.2 Preliminaries</H2>
|
||||
<H2><a name="Python_nn3">36.2 Preliminaries</a></H2>
|
||||
|
||||
|
||||
<H3><a name="Python_nn4"></a>36.2.1 Running SWIG</H3>
|
||||
<H3><a name="Python_nn4">36.2.1 Running SWIG</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -276,7 +276,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"></a>36.2.2 Using distutils</H3>
|
||||
<H3><a name="Python_nn6">36.2.2 Using distutils</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -368,7 +368,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"></a>36.2.3 Hand compiling a dynamic module</H3>
|
||||
<H3><a name="Python_nn7">36.2.3 Hand compiling a dynamic module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -416,7 +416,7 @@ module actually consists of two files; <tt>socket.py</tt> and
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn8"></a>36.2.4 Static linking</H3>
|
||||
<H3><a name="Python_nn8">36.2.4 Static linking</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -495,7 +495,7 @@ If using static linking, you might want to rely on a different approach
|
|||
(perhaps using distutils).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn9"></a>36.2.5 Using your module</H3>
|
||||
<H3><a name="Python_nn9">36.2.5 Using your module</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -652,7 +652,7 @@ system configuration (this requires root access and you will need to
|
|||
read the man pages).
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn10"></a>36.2.6 Compilation of C++ extensions</H3>
|
||||
<H3><a name="Python_nn10">36.2.6 Compilation of C++ extensions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -744,7 +744,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"></a>36.2.7 Compiling for 64-bit platforms</H3>
|
||||
<H3><a name="Python_nn11">36.2.7 Compiling for 64-bit platforms</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -781,7 +781,7 @@ and -m64 allow you to choose the desired binary format for your python
|
|||
extension.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn12"></a>36.2.8 Building Python Extensions under Windows</H3>
|
||||
<H3><a name="Python_nn12">36.2.8 Building Python Extensions under Windows</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -910,7 +910,7 @@ SWIG Wiki</a>.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn13"></a>36.3 A tour of basic C/C++ wrapping</H2>
|
||||
<H2><a name="Python_nn13">36.3 A tour of basic C/C++ wrapping</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -919,7 +919,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"></a>36.3.1 Modules</H3>
|
||||
<H3><a name="Python_nn14">36.3.1 Modules</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -932,7 +932,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"></a>36.3.2 Functions</H3>
|
||||
<H3><a name="Python_nn15">36.3.2 Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -956,7 +956,7 @@ like you think it does:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn16"></a>36.3.3 Global variables</H3>
|
||||
<H3><a name="Python_nn16">36.3.3 Global variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1094,7 +1094,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"></a>36.3.4 Constants and enums</H3>
|
||||
<H3><a name="Python_nn17">36.3.4 Constants and enums</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1134,7 +1134,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"></a>36.3.5 Pointers</H3>
|
||||
<H3><a name="Python_nn18">36.3.5 Pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1275,7 +1275,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"></a>36.3.6 Structures</H3>
|
||||
<H3><a name="Python_nn19">36.3.6 Structures</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1464,7 +1464,7 @@ everything works just like you would expect. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn20"></a>36.3.7 C++ classes</H3>
|
||||
<H3><a name="Python_nn20">36.3.7 C++ classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1553,7 +1553,7 @@ they are accessed through <tt>cvar</tt> like this:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn21"></a>36.3.8 C++ inheritance</H3>
|
||||
<H3><a name="Python_nn21">36.3.8 C++ inheritance</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1608,7 +1608,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"></a>36.3.9 Pointers, references, values, and arrays</H3>
|
||||
<H3><a name="Python_nn22">36.3.9 Pointers, references, values, and arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1669,7 +1669,7 @@ treated as a returning value, and it will follow the same
|
|||
allocation/deallocation process.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn23"></a>36.3.10 C++ overloaded functions</H3>
|
||||
<H3><a name="Python_nn23">36.3.10 C++ overloaded functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1792,7 +1792,7 @@ first declaration takes precedence.
|
|||
Please refer to the "SWIG and C++" chapter for more information about overloading.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn24"></a>36.3.11 C++ operators</H3>
|
||||
<H3><a name="Python_nn24">36.3.11 C++ operators</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1881,7 +1881,7 @@ Also, be aware that certain operators don't map cleanly to Python. For instance
|
|||
overloaded assignment operators don't map to Python semantics and will be ignored.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn25"></a>36.3.12 C++ namespaces</H3>
|
||||
<H3><a name="Python_nn25">36.3.12 C++ namespaces</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -1948,7 +1948,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"></a>36.3.13 C++ templates</H3>
|
||||
<H3><a name="Python_nn26">36.3.13 C++ templates</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2002,10 +2002,10 @@ Some more complicated
|
|||
examples will appear later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn27"></a>36.3.14 C++ Smart Pointers</H3>
|
||||
<H3><a name="Python_nn27">36.3.14 C++ Smart Pointers</a></H3>
|
||||
|
||||
|
||||
<H4><a name="Python_smart_pointers_shared_ptr"></a>36.3.14.1 The shared_ptr Smart Pointer</H4>
|
||||
<H4><a name="Python_smart_pointers_shared_ptr">36.3.14.1 The shared_ptr Smart Pointer</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2016,7 +2016,7 @@ in the <a href="Library.html#Library_std_shared_ptr">shared_ptr smart pointer</a
|
|||
</p>
|
||||
|
||||
|
||||
<H4><a name="Python_smart_pointers_generic"></a>36.3.14.2 Generic Smart Pointers</H4>
|
||||
<H4><a name="Python_smart_pointers_generic">36.3.14.2 Generic Smart Pointers</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2100,7 +2100,7 @@ simply use the <tt>__deref__()</tt> method. For example:
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn27a"></a>36.3.15 C++ reference counted objects</H3>
|
||||
<H3><a name="Python_nn27a">36.3.15 C++ reference counted objects</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2109,7 +2109,7 @@ Python examples of memory management using referencing counting.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn28"></a>36.4 Further details on the Python class interface</H2>
|
||||
<H2><a name="Python_nn28">36.4 Further details on the Python class interface</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2132,7 +2132,7 @@ the <tt>-builtin</tt> option are in the <a href="#Python_builtin_types">Built-in
|
|||
section.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn29"></a>36.4.1 Proxy classes</H3>
|
||||
<H3><a name="Python_nn29">36.4.1 Proxy classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2221,7 +2221,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"></a>36.4.2 Built-in Types</H3>
|
||||
<H3><a name="Python_builtin_types">36.4.2 Built-in Types</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2265,7 +2265,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"></a>36.4.2.1 Limitations</H4>
|
||||
<H4><a name="Python_builtin_limitations">36.4.2.1 Limitations</a></H4>
|
||||
|
||||
|
||||
<p>Use of the <tt>-builtin</tt> option implies a couple of limitations:
|
||||
|
|
@ -2433,7 +2433,7 @@ assert(issubclass(B.Derived, A.Base))
|
|||
</li>
|
||||
</ul>
|
||||
|
||||
<H4><a name="Python_builtin_overloads"></a>36.4.2.2 Operator overloads -- use them!</H4>
|
||||
<H4><a name="Python_builtin_overloads">36.4.2.2 Operator overloads -- use them!</a></H4>
|
||||
|
||||
|
||||
<p>The entire justification for the <tt>-builtin</tt> option is improved
|
||||
|
|
@ -2534,7 +2534,7 @@ structs.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn30"></a>36.4.3 Memory management</H3>
|
||||
<H3><a name="Python_nn30">36.4.3 Memory management</a></H3>
|
||||
|
||||
|
||||
<p>NOTE: Although this section refers to proxy objects, everything here also applies
|
||||
|
|
@ -2729,7 +2729,7 @@ It is also possible to deal with situations like this using
|
|||
typemaps--an advanced topic discussed later.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn31"></a>36.4.4 Python 2.2 and classic classes</H3>
|
||||
<H3><a name="Python_nn31">36.4.4 Python 2.2 and classic classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2766,7 +2766,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"></a>36.5 Cross language polymorphism</H2>
|
||||
<H2><a name="Python_directors">36.5 Cross language polymorphism</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2800,7 +2800,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"></a>36.5.1 Enabling directors</H3>
|
||||
<H3><a name="Python_nn33">36.5.1 Enabling directors</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -2892,7 +2892,7 @@ class MyFoo(mymodule.Foo):
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn34"></a>36.5.2 Director classes</H3>
|
||||
<H3><a name="Python_nn34">36.5.2 Director classes</a></H3>
|
||||
|
||||
|
||||
|
||||
|
|
@ -2974,7 +2974,7 @@ so there is no need for the extra overhead involved with routing the
|
|||
calls through Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn35"></a>36.5.3 Ownership and object destruction</H3>
|
||||
<H3><a name="Python_nn35">36.5.3 Ownership and object destruction</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3041,7 +3041,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"></a>36.5.4 Exception unrolling</H3>
|
||||
<H3><a name="Python_nn36">36.5.4 Exception unrolling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3100,7 +3100,7 @@ Swig::DirectorMethodException is thrown, Python will register the
|
|||
exception as soon as the C wrapper function returns.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn37"></a>36.5.5 Overhead and code bloat</H3>
|
||||
<H3><a name="Python_nn37">36.5.5 Overhead and code bloat</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3134,7 +3134,7 @@ directive) for only those methods that are likely to be extended in
|
|||
Python.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn38"></a>36.5.6 Typemaps</H3>
|
||||
<H3><a name="Python_nn38">36.5.6 Typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3148,7 +3148,7 @@ need to be supported.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn39"></a>36.5.7 Miscellaneous</H3>
|
||||
<H3><a name="Python_nn39">36.5.7 Miscellaneous</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3195,7 +3195,7 @@ methods that return const references.
|
|||
</p>
|
||||
|
||||
|
||||
<H2><a name="Python_nn40"></a>36.6 Common customization features</H2>
|
||||
<H2><a name="Python_nn40">36.6 Common customization features</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3208,7 +3208,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"></a>36.6.1 C/C++ helper functions</H3>
|
||||
<H3><a name="Python_nn41">36.6.1 C/C++ helper functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3289,7 +3289,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"></a>36.6.2 Adding additional Python code</H3>
|
||||
<H3><a name="Python_nn42">36.6.2 Adding additional Python code</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3541,7 +3541,7 @@ The same applies for overloaded constructors.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn43"></a>36.6.3 Class extension with %extend</H3>
|
||||
<H3><a name="Python_nn43">36.6.3 Class extension with %extend</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3630,7 +3630,7 @@ Vector(12,14,16)
|
|||
in any way---the extensions only show up in the Python interface.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn44"></a>36.6.4 Exception handling with %exception</H3>
|
||||
<H3><a name="Python_nn44">36.6.4 Exception handling with %exception</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3756,7 +3756,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"></a>36.7 Tips and techniques</H2>
|
||||
<H2><a name="Python_nn45">36.7 Tips and techniques</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3766,7 +3766,7 @@ strings, binary data, and arrays. This chapter discusses the common techniques
|
|||
solving these problems.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn46"></a>36.7.1 Input and output parameters</H3>
|
||||
<H3><a name="Python_nn46">36.7.1 Input and output parameters</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -3979,7 +3979,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"></a>36.7.2 Simple pointers</H3>
|
||||
<H3><a name="Python_nn47">36.7.2 Simple pointers</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4048,7 +4048,7 @@ If you replace <tt>%pointer_functions()</tt> by <tt>%pointer_class(type,name)</t
|
|||
See the <a href="Library.html#Library">SWIG Library</a> chapter for further details.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn48"></a>36.7.3 Unbounded C Arrays</H3>
|
||||
<H3><a name="Python_nn48">36.7.3 Unbounded C Arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4110,7 +4110,7 @@ well suited for applications in which you need to create buffers,
|
|||
package binary data, etc.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn49"></a>36.7.4 String handling</H3>
|
||||
<H3><a name="Python_nn49">36.7.4 String handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4180,7 +4180,7 @@ also be used to extra binary data from arbitrary pointers.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_default_args"></a>36.7.5 Default arguments</H3>
|
||||
<H3><a name="Python_default_args">36.7.5 Default arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4279,7 +4279,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"></a>36.8 Typemaps</H2>
|
||||
<H2><a name="Python_nn53">36.8 Typemaps</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4296,7 +4296,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"></a>36.8.1 What is a typemap?</H3>
|
||||
<H3><a name="Python_nn54">36.8.1 What is a typemap?</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4412,7 +4412,7 @@ parameter is omitted):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn55"></a>36.8.2 Python typemaps</H3>
|
||||
<H3><a name="Python_nn55">36.8.2 Python typemaps</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4453,7 +4453,7 @@ a look at the SWIG library version 1.3.20 or so.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn56"></a>36.8.3 Typemap variables</H3>
|
||||
<H3><a name="Python_nn56">36.8.3 Typemap variables</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4524,7 +4524,7 @@ properly assigned.
|
|||
The Python name of the wrapper function being created.
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn57"></a>36.8.4 Useful Python Functions</H3>
|
||||
<H3><a name="Python_nn57">36.8.4 Useful Python Functions</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4652,7 +4652,7 @@ write me
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn58"></a>36.9 Typemap Examples</H2>
|
||||
<H2><a name="Python_nn58">36.9 Typemap Examples</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4661,7 +4661,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"></a>36.9.1 Converting Python list to a char ** </H3>
|
||||
<H3><a name="Python_nn59">36.9.1 Converting Python list to a char ** </a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4741,7 +4741,7 @@ memory allocation is used to allocate memory for the array, the
|
|||
the C function.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn60"></a>36.9.2 Expanding a Python object into multiple arguments</H3>
|
||||
<H3><a name="Python_nn60">36.9.2 Expanding a Python object into multiple arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4820,7 +4820,7 @@ to supply the argument count. This is automatically set by the typemap code. F
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn61"></a>36.9.3 Using typemaps to return arguments</H3>
|
||||
<H3><a name="Python_nn61">36.9.3 Using typemaps to return arguments</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4908,7 +4908,7 @@ function can now be used as follows:
|
|||
>>>
|
||||
</pre></div>
|
||||
|
||||
<H3><a name="Python_nn62"></a>36.9.4 Mapping Python tuples into small arrays</H3>
|
||||
<H3><a name="Python_nn62">36.9.4 Mapping Python tuples into small arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -4957,7 +4957,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"></a>36.9.5 Mapping sequences to C arrays</H3>
|
||||
<H3><a name="Python_nn63">36.9.5 Mapping sequences to C arrays</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5046,7 +5046,7 @@ static int convert_darray(PyObject *input, double *ptr, int size) {
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_nn64"></a>36.9.6 Pointer handling</H3>
|
||||
<H3><a name="Python_nn64">36.9.6 Pointer handling</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5143,7 +5143,7 @@ class object (if applicable).
|
|||
|
||||
|
||||
|
||||
<H2><a name="Python_nn65"></a>36.10 Docstring Features</H2>
|
||||
<H2><a name="Python_nn65">36.10 Docstring Features</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5171,7 +5171,7 @@ of your users much simpler.
|
|||
</p>
|
||||
|
||||
|
||||
<H3><a name="Python_nn66"></a>36.10.1 Module docstring</H3>
|
||||
<H3><a name="Python_nn66">36.10.1 Module docstring</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5205,7 +5205,7 @@ layout of controls on a panel, etc. to be loaded from an XML file."
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn67"></a>36.10.2 %feature("autodoc")</H3>
|
||||
<H3><a name="Python_nn67">36.10.2 %feature("autodoc")</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5233,7 +5233,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"></a>36.10.2.1 %feature("autodoc", "0")</H4>
|
||||
<H4><a name="Python_nn68">36.10.2.1 %feature("autodoc", "0")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5262,7 +5262,7 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_nn69"></a>36.10.2.2 %feature("autodoc", "1")</H4>
|
||||
<H4><a name="Python_nn69">36.10.2.2 %feature("autodoc", "1")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5287,7 +5287,7 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_autodoc2"></a>36.10.2.3 %feature("autodoc", "2")</H4>
|
||||
<H4><a name="Python_autodoc2">36.10.2.3 %feature("autodoc", "2")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5349,7 +5349,7 @@ def function_name(*args, **kwargs):
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H4><a name="Python_autodoc3"></a>36.10.2.4 %feature("autodoc", "3")</H4>
|
||||
<H4><a name="Python_autodoc3">36.10.2.4 %feature("autodoc", "3")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5375,7 +5375,7 @@ def function_name(*args, **kwargs):
|
|||
</div>
|
||||
|
||||
|
||||
<H4><a name="Python_nn70"></a>36.10.2.5 %feature("autodoc", "docstring")</H4>
|
||||
<H4><a name="Python_nn70">36.10.2.5 %feature("autodoc", "docstring")</a></H4>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5394,7 +5394,7 @@ void GetPosition(int* OUTPUT, int* OUTPUT);
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn71"></a>36.10.3 %feature("docstring")</H3>
|
||||
<H3><a name="Python_nn71">36.10.3 %feature("docstring")</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5426,7 +5426,7 @@ with more than one line.
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H2><a name="Python_nn72"></a>36.11 Python Packages</H2>
|
||||
<H2><a name="Python_nn72">36.11 Python Packages</a></H2>
|
||||
|
||||
|
||||
<p>Python has concepts of modules and packages. Modules are separate units of
|
||||
|
|
@ -5484,7 +5484,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"></a>36.11.1 Setting the Python package</H3>
|
||||
<H3><a name="Python_modulepackage">36.11.1 Setting the Python package</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5538,7 +5538,7 @@ pkg1/pkg2/_foo.so # (shared library built from C/C++ code generated by SWI
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_absrelimports"></a>36.11.2 Absolute and relative imports</H3>
|
||||
<H3><a name="Python_absrelimports">36.11.2 Absolute and relative imports</a></H3>
|
||||
|
||||
|
||||
<p>Suppose, we have the following hierarchy of files:</p>
|
||||
|
|
@ -5677,7 +5677,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"></a>36.11.3 Enforcing absolute import semantics</H3>
|
||||
<H3><a name="Python_absimport">36.11.3 Enforcing absolute import semantics</a></H3>
|
||||
|
||||
|
||||
<p>As you may know, there is an incompatibility in import semantics (for the
|
||||
|
|
@ -5714,7 +5714,7 @@ from __future__ import absolute_import
|
|||
</pre>
|
||||
</div>
|
||||
|
||||
<H3><a name="Python_importfrominit"></a>36.11.4 Importing from __init__.py</H3>
|
||||
<H3><a name="Python_importfrominit">36.11.4 Importing from __init__.py</a></H3>
|
||||
|
||||
|
||||
<p>Imports in <tt>__init__.py</tt> are handy when you want to populate a
|
||||
|
|
@ -5825,7 +5825,7 @@ effect (note, that the Python 2 case also needs the <tt>-relativeimport</tt>
|
|||
workaround).</p>
|
||||
|
||||
|
||||
<H2><a name="Python_python3support"></a>36.12 Python 3 Support</H2>
|
||||
<H2><a name="Python_python3support">36.12 Python 3 Support</a></H2>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5852,7 +5852,7 @@ The following are Python 3.0 new features that are currently supported by
|
|||
SWIG.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_nn74"></a>36.12.1 Function annotation</H3>
|
||||
<H3><a name="Python_nn74">36.12.1 Function annotation</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -5885,7 +5885,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"></a>36.12.2 Buffer interface</H3>
|
||||
<H3><a name="Python_nn75">36.12.2 Buffer interface</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6037,7 +6037,7 @@ modify the buffer.
|
|||
</div>
|
||||
|
||||
|
||||
<H3><a name="Python_nn76"></a>36.12.3 Abstract base classes</H3>
|
||||
<H3><a name="Python_nn76">36.12.3 Abstract base classes</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6078,7 +6078,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"></a>36.12.4 Byte string output conversion</H3>
|
||||
<H3><a name="Python_nn77">36.12.4 Byte string output conversion</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
@ -6164,7 +6164,7 @@ For more details about the <tt>surrogateescape</tt> error handler, please see
|
|||
<a href="https://www.python.org/dev/peps/pep-0383/">PEP 383</a>.
|
||||
</p>
|
||||
|
||||
<H3><a name="Python_2_unicode"></a>36.12.5 Python 2 Unicode</H3>
|
||||
<H3><a name="Python_2_unicode">36.12.5 Python 2 Unicode</a></H3>
|
||||
|
||||
|
||||
<p>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue