803 lines
74 KiB
HTML
803 lines
74 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<title>Introduction — Python 3.7.4 documentation</title>
|
||
<link rel="stylesheet" href="../_static/pydoctheme.css" type="text/css" />
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
|
||
|
||
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
|
||
<script type="text/javascript" src="../_static/jquery.js"></script>
|
||
<script type="text/javascript" src="../_static/underscore.js"></script>
|
||
<script type="text/javascript" src="../_static/doctools.js"></script>
|
||
<script type="text/javascript" src="../_static/language_data.js"></script>
|
||
|
||
<script type="text/javascript" src="../_static/sidebar.js"></script>
|
||
|
||
<link rel="search" type="application/opensearchdescription+xml"
|
||
title="Search within Python 3.7.4 documentation"
|
||
href="../_static/opensearch.xml"/>
|
||
<link rel="author" title="About these documents" href="../about.html" />
|
||
<link rel="index" title="Index" href="../genindex.html" />
|
||
<link rel="search" title="Search" href="../search.html" />
|
||
<link rel="copyright" title="Copyright" href="../copyright.html" />
|
||
<link rel="next" title="Stable Application Binary Interface" href="stable.html" />
|
||
<link rel="prev" title="Python/C API Reference Manual" href="index.html" />
|
||
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
|
||
<link rel="canonical" href="https://docs.python.org/3/c-api/intro.html" />
|
||
|
||
<script type="text/javascript" src="../_static/copybutton.js"></script>
|
||
<script type="text/javascript" src="../_static/switchers.js"></script>
|
||
|
||
|
||
|
||
<style>
|
||
@media only screen {
|
||
table.full-width-table {
|
||
width: 100%;
|
||
}
|
||
}
|
||
</style>
|
||
|
||
|
||
</head><body>
|
||
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="../genindex.html" title="General Index"
|
||
accesskey="I">index</a></li>
|
||
<li class="right" >
|
||
<a href="../py-modindex.html" title="Python Module Index"
|
||
>modules</a> |</li>
|
||
<li class="right" >
|
||
<a href="stable.html" title="Stable Application Binary Interface"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="index.html" title="Python/C API Reference Manual"
|
||
accesskey="P">previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" accesskey="U">Python/C API Reference Manual</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<div class="document">
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
<div class="body" role="main">
|
||
|
||
<div class="section" id="introduction">
|
||
<span id="api-intro"></span><h1>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h1>
|
||
<p>The Application Programmer’s Interface to Python gives C and C++ programmers
|
||
access to the Python interpreter at a variety of levels. The API is equally
|
||
usable from C++, but for brevity it is generally referred to as the Python/C
|
||
API. There are two fundamentally different reasons for using the Python/C API.
|
||
The first reason is to write <em>extension modules</em> for specific purposes; these
|
||
are C modules that extend the Python interpreter. This is probably the most
|
||
common use. The second reason is to use Python as a component in a larger
|
||
application; this technique is generally referred to as <em class="dfn">embedding</em> Python
|
||
in an application.</p>
|
||
<p>Writing an extension module is a relatively well-understood process, where a
|
||
“cookbook” approach works well. There are several tools that automate the
|
||
process to some extent. While people have embedded Python in other
|
||
applications since its early existence, the process of embedding Python is
|
||
less straightforward than writing an extension.</p>
|
||
<p>Many API functions are useful independent of whether you’re embedding or
|
||
extending Python; moreover, most applications that embed Python will need to
|
||
provide a custom extension as well, so it’s probably a good idea to become
|
||
familiar with writing an extension before attempting to embed Python in a real
|
||
application.</p>
|
||
<div class="section" id="coding-standards">
|
||
<h2>Coding standards<a class="headerlink" href="#coding-standards" title="Permalink to this headline">¶</a></h2>
|
||
<p>If you’re writing C code for inclusion in CPython, you <strong>must</strong> follow the
|
||
guidelines and standards defined in <span class="target" id="index-0"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0007"><strong>PEP 7</strong></a>. These guidelines apply
|
||
regardless of the version of Python you are contributing to. Following these
|
||
conventions is not necessary for your own third party extension modules,
|
||
unless you eventually expect to contribute them to Python.</p>
|
||
</div>
|
||
<div class="section" id="include-files">
|
||
<span id="api-includes"></span><h2>Include Files<a class="headerlink" href="#include-files" title="Permalink to this headline">¶</a></h2>
|
||
<p>All function, type and macro definitions needed to use the Python/C API are
|
||
included in your code by the following line:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="cp">#define PY_SSIZE_T_CLEAN</span>
|
||
<span class="cp">#include</span> <span class="cpf"><Python.h></span><span class="cp"></span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This implies inclusion of the following standard headers: <code class="docutils literal notranslate"><span class="pre"><stdio.h></span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre"><string.h></span></code>, <code class="docutils literal notranslate"><span class="pre"><errno.h></span></code>, <code class="docutils literal notranslate"><span class="pre"><limits.h></span></code>, <code class="docutils literal notranslate"><span class="pre"><assert.h></span></code> and <code class="docutils literal notranslate"><span class="pre"><stdlib.h></span></code>
|
||
(if available).</p>
|
||
<div class="admonition note">
|
||
<p class="admonition-title">Note</p>
|
||
<p>Since Python may define some pre-processor definitions which affect the standard
|
||
headers on some systems, you <em>must</em> include <code class="file docutils literal notranslate"><span class="pre">Python.h</span></code> before any standard
|
||
headers are included.</p>
|
||
<p>It is recommended to always define <code class="docutils literal notranslate"><span class="pre">PY_SSIZE_T_CLEAN</span></code> before including
|
||
<code class="docutils literal notranslate"><span class="pre">Python.h</span></code>. See <a class="reference internal" href="arg.html#arg-parsing"><span class="std std-ref">Parsing arguments and building values</span></a> for a description of this macro.</p>
|
||
</div>
|
||
<p>All user visible names defined by Python.h (except those defined by the included
|
||
standard headers) have one of the prefixes <code class="docutils literal notranslate"><span class="pre">Py</span></code> or <code class="docutils literal notranslate"><span class="pre">_Py</span></code>. Names beginning
|
||
with <code class="docutils literal notranslate"><span class="pre">_Py</span></code> are for internal use by the Python implementation and should not be
|
||
used by extension writers. Structure member names do not have a reserved prefix.</p>
|
||
<p><strong>Important:</strong> user code should never define names that begin with <code class="docutils literal notranslate"><span class="pre">Py</span></code> or
|
||
<code class="docutils literal notranslate"><span class="pre">_Py</span></code>. This confuses the reader, and jeopardizes the portability of the user
|
||
code to future Python versions, which may define additional names beginning with
|
||
one of these prefixes.</p>
|
||
<p>The header files are typically installed with Python. On Unix, these are
|
||
located in the directories <code class="file docutils literal notranslate"><em><span class="pre">prefix</span></em><span class="pre">/include/pythonversion/</span></code> and
|
||
<code class="file docutils literal notranslate"><em><span class="pre">exec_prefix</span></em><span class="pre">/include/pythonversion/</span></code>, where <span class="target" id="index-1"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">prefix</span></code> and
|
||
<span class="target" id="index-2"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">exec_prefix</span></code> are defined by the corresponding parameters to Python’s
|
||
<strong class="program">configure</strong> script and <em>version</em> is
|
||
<code class="docutils literal notranslate"><span class="pre">'%d.%d'</span> <span class="pre">%</span> <span class="pre">sys.version_info[:2]</span></code>. On Windows, the headers are installed
|
||
in <code class="file docutils literal notranslate"><em><span class="pre">prefix</span></em><span class="pre">/include</span></code>, where <span class="target" id="index-3"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">prefix</span></code> is the installation
|
||
directory specified to the installer.</p>
|
||
<p>To include the headers, place both directories (if different) on your compiler’s
|
||
search path for includes. Do <em>not</em> place the parent directories on the search
|
||
path and then use <code class="docutils literal notranslate"><span class="pre">#include</span> <span class="pre"><pythonX.Y/Python.h></span></code>; this will break on
|
||
multi-platform builds since the platform independent headers under
|
||
<span class="target" id="index-4"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">prefix</span></code> include the platform specific headers from
|
||
<span class="target" id="index-5"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">exec_prefix</span></code>.</p>
|
||
<p>C++ users should note that though the API is defined entirely using C, the
|
||
header files do properly declare the entry points to be <code class="docutils literal notranslate"><span class="pre">extern</span> <span class="pre">"C"</span></code>, so there
|
||
is no need to do anything special to use the API from C++.</p>
|
||
</div>
|
||
<div class="section" id="useful-macros">
|
||
<h2>Useful macros<a class="headerlink" href="#useful-macros" title="Permalink to this headline">¶</a></h2>
|
||
<p>Several useful macros are defined in the Python header files. Many are
|
||
defined closer to where they are useful (e.g. <a class="reference internal" href="none.html#c.Py_RETURN_NONE" title="Py_RETURN_NONE"><code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_RETURN_NONE</span></code></a>).
|
||
Others of a more general utility are defined here. This is not necessarily a
|
||
complete listing.</p>
|
||
<dl class="macro">
|
||
<dt id="c.Py_UNREACHABLE">
|
||
<code class="descname">Py_UNREACHABLE</code><span class="sig-paren">(</span><span class="sig-paren">)</span><a class="headerlink" href="#c.Py_UNREACHABLE" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Use this when you have a code path that you do not expect to be reached.
|
||
For example, in the <code class="docutils literal notranslate"><span class="pre">default:</span></code> clause in a <code class="docutils literal notranslate"><span class="pre">switch</span></code> statement for which
|
||
all possible values are covered in <code class="docutils literal notranslate"><span class="pre">case</span></code> statements. Use this in places
|
||
where you might be tempted to put an <code class="docutils literal notranslate"><span class="pre">assert(0)</span></code> or <code class="docutils literal notranslate"><span class="pre">abort()</span></code> call.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.7.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_ABS">
|
||
<code class="descname">Py_ABS</code><span class="sig-paren">(</span>x<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_ABS" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Return the absolute value of <code class="docutils literal notranslate"><span class="pre">x</span></code>.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.3.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_MIN">
|
||
<code class="descname">Py_MIN</code><span class="sig-paren">(</span>x, y<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_MIN" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Return the minimum value between <code class="docutils literal notranslate"><span class="pre">x</span></code> and <code class="docutils literal notranslate"><span class="pre">y</span></code>.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.3.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_MAX">
|
||
<code class="descname">Py_MAX</code><span class="sig-paren">(</span>x, y<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_MAX" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Return the maximum value between <code class="docutils literal notranslate"><span class="pre">x</span></code> and <code class="docutils literal notranslate"><span class="pre">y</span></code>.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.3.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_STRINGIFY">
|
||
<code class="descname">Py_STRINGIFY</code><span class="sig-paren">(</span>x<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_STRINGIFY" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Convert <code class="docutils literal notranslate"><span class="pre">x</span></code> to a C string. E.g. <code class="docutils literal notranslate"><span class="pre">Py_STRINGIFY(123)</span></code> returns
|
||
<code class="docutils literal notranslate"><span class="pre">"123"</span></code>.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.4.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_MEMBER_SIZE">
|
||
<code class="descname">Py_MEMBER_SIZE</code><span class="sig-paren">(</span>type, member<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_MEMBER_SIZE" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Return the size of a structure (<code class="docutils literal notranslate"><span class="pre">type</span></code>) <code class="docutils literal notranslate"><span class="pre">member</span></code> in bytes.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.6.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_CHARMASK">
|
||
<code class="descname">Py_CHARMASK</code><span class="sig-paren">(</span>c<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_CHARMASK" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Argument must be a character or an integer in the range [-128, 127] or [0,
|
||
255]. This macro returns <code class="docutils literal notranslate"><span class="pre">c</span></code> cast to an <code class="docutils literal notranslate"><span class="pre">unsigned</span> <span class="pre">char</span></code>.</p>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_GETENV">
|
||
<code class="descname">Py_GETENV</code><span class="sig-paren">(</span>s<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_GETENV" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Like <code class="docutils literal notranslate"><span class="pre">getenv(s)</span></code>, but returns <em>NULL</em> if <a class="reference internal" href="../using/cmdline.html#cmdoption-e"><code class="xref std std-option docutils literal notranslate"><span class="pre">-E</span></code></a> was passed on the
|
||
command line (i.e. if <code class="docutils literal notranslate"><span class="pre">Py_IgnoreEnvironmentFlag</span></code> is set).</p>
|
||
</dd></dl>
|
||
|
||
<dl class="macro">
|
||
<dt id="c.Py_UNUSED">
|
||
<code class="descname">Py_UNUSED</code><span class="sig-paren">(</span>arg<span class="sig-paren">)</span><a class="headerlink" href="#c.Py_UNUSED" title="Permalink to this definition">¶</a></dt>
|
||
<dd><p>Use this for unused arguments in a function definition to silence compiler
|
||
warnings, e.g. <code class="docutils literal notranslate"><span class="pre">PyObject*</span> <span class="pre">func(PyObject</span> <span class="pre">*Py_UNUSED(ignored))</span></code>.</p>
|
||
<div class="versionadded">
|
||
<p><span class="versionmodified added">New in version 3.4.</span></p>
|
||
</div>
|
||
</dd></dl>
|
||
|
||
</div>
|
||
<div class="section" id="objects-types-and-reference-counts">
|
||
<span id="api-objects"></span><h2>Objects, Types and Reference Counts<a class="headerlink" href="#objects-types-and-reference-counts" title="Permalink to this headline">¶</a></h2>
|
||
<p id="index-6">Most Python/C API functions have one or more arguments as well as a return value
|
||
of type <a class="reference internal" href="structures.html#c.PyObject" title="PyObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyObject*</span></code></a>. This type is a pointer to an opaque data type
|
||
representing an arbitrary Python object. Since all Python object types are
|
||
treated the same way by the Python language in most situations (e.g.,
|
||
assignments, scope rules, and argument passing), it is only fitting that they
|
||
should be represented by a single C type. Almost all Python objects live on the
|
||
heap: you never declare an automatic or static variable of type
|
||
<a class="reference internal" href="structures.html#c.PyObject" title="PyObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyObject</span></code></a>, only pointer variables of type <a class="reference internal" href="structures.html#c.PyObject" title="PyObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyObject*</span></code></a> can be
|
||
declared. The sole exception are the type objects; since these must never be
|
||
deallocated, they are typically static <a class="reference internal" href="type.html#c.PyTypeObject" title="PyTypeObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyTypeObject</span></code></a> objects.</p>
|
||
<p>All Python objects (even Python integers) have a <em class="dfn">type</em> and a
|
||
<em class="dfn">reference count</em>. An object’s type determines what kind of object it is
|
||
(e.g., an integer, a list, or a user-defined function; there are many more as
|
||
explained in <a class="reference internal" href="../reference/datamodel.html#types"><span class="std std-ref">The standard type hierarchy</span></a>). For each of the well-known types there is a macro
|
||
to check whether an object is of that type; for instance, <code class="docutils literal notranslate"><span class="pre">PyList_Check(a)</span></code> is
|
||
true if (and only if) the object pointed to by <em>a</em> is a Python list.</p>
|
||
<div class="section" id="reference-counts">
|
||
<span id="api-refcounts"></span><h3>Reference Counts<a class="headerlink" href="#reference-counts" title="Permalink to this headline">¶</a></h3>
|
||
<p>The reference count is important because today’s computers have a finite (and
|
||
often severely limited) memory size; it counts how many different places there
|
||
are that have a reference to an object. Such a place could be another object,
|
||
or a global (or static) C variable, or a local variable in some C function.
|
||
When an object’s reference count becomes zero, the object is deallocated. If
|
||
it contains references to other objects, their reference count is decremented.
|
||
Those other objects may be deallocated in turn, if this decrement makes their
|
||
reference count become zero, and so on. (There’s an obvious problem with
|
||
objects that reference each other here; for now, the solution is “don’t do
|
||
that.”)</p>
|
||
<p id="index-7">Reference counts are always manipulated explicitly. The normal way is to use
|
||
the macro <a class="reference internal" href="refcounting.html#c.Py_INCREF" title="Py_INCREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_INCREF()</span></code></a> to increment an object’s reference count by one,
|
||
and <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a> to decrement it by one. The <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a> macro
|
||
is considerably more complex than the incref one, since it must check whether
|
||
the reference count becomes zero and then cause the object’s deallocator to be
|
||
called. The deallocator is a function pointer contained in the object’s type
|
||
structure. The type-specific deallocator takes care of decrementing the
|
||
reference counts for other objects contained in the object if this is a compound
|
||
object type, such as a list, as well as performing any additional finalization
|
||
that’s needed. There’s no chance that the reference count can overflow; at
|
||
least as many bits are used to hold the reference count as there are distinct
|
||
memory locations in virtual memory (assuming <code class="docutils literal notranslate"><span class="pre">sizeof(Py_ssize_t)</span> <span class="pre">>=</span> <span class="pre">sizeof(void*)</span></code>).
|
||
Thus, the reference count increment is a simple operation.</p>
|
||
<p>It is not necessary to increment an object’s reference count for every local
|
||
variable that contains a pointer to an object. In theory, the object’s
|
||
reference count goes up by one when the variable is made to point to it and it
|
||
goes down by one when the variable goes out of scope. However, these two
|
||
cancel each other out, so at the end the reference count hasn’t changed. The
|
||
only real reason to use the reference count is to prevent the object from being
|
||
deallocated as long as our variable is pointing to it. If we know that there
|
||
is at least one other reference to the object that lives at least as long as
|
||
our variable, there is no need to increment the reference count temporarily.
|
||
An important situation where this arises is in objects that are passed as
|
||
arguments to C functions in an extension module that are called from Python;
|
||
the call mechanism guarantees to hold a reference to every argument for the
|
||
duration of the call.</p>
|
||
<p>However, a common pitfall is to extract an object from a list and hold on to it
|
||
for a while without incrementing its reference count. Some other operation might
|
||
conceivably remove the object from the list, decrementing its reference count
|
||
and possible deallocating it. The real danger is that innocent-looking
|
||
operations may invoke arbitrary Python code which could do this; there is a code
|
||
path which allows control to flow back to the user from a <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a>, so
|
||
almost any operation is potentially dangerous.</p>
|
||
<p>A safe approach is to always use the generic operations (functions whose name
|
||
begins with <code class="docutils literal notranslate"><span class="pre">PyObject_</span></code>, <code class="docutils literal notranslate"><span class="pre">PyNumber_</span></code>, <code class="docutils literal notranslate"><span class="pre">PySequence_</span></code> or <code class="docutils literal notranslate"><span class="pre">PyMapping_</span></code>).
|
||
These operations always increment the reference count of the object they return.
|
||
This leaves the caller with the responsibility to call <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a> when
|
||
they are done with the result; this soon becomes second nature.</p>
|
||
<div class="section" id="reference-count-details">
|
||
<span id="api-refcountdetails"></span><h4>Reference Count Details<a class="headerlink" href="#reference-count-details" title="Permalink to this headline">¶</a></h4>
|
||
<p>The reference count behavior of functions in the Python/C API is best explained
|
||
in terms of <em>ownership of references</em>. Ownership pertains to references, never
|
||
to objects (objects are not owned: they are always shared). “Owning a
|
||
reference” means being responsible for calling Py_DECREF on it when the
|
||
reference is no longer needed. Ownership can also be transferred, meaning that
|
||
the code that receives ownership of the reference then becomes responsible for
|
||
eventually decref’ing it by calling <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a> or <a class="reference internal" href="refcounting.html#c.Py_XDECREF" title="Py_XDECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_XDECREF()</span></code></a>
|
||
when it’s no longer needed—or passing on this responsibility (usually to its
|
||
caller). When a function passes ownership of a reference on to its caller, the
|
||
caller is said to receive a <em>new</em> reference. When no ownership is transferred,
|
||
the caller is said to <em>borrow</em> the reference. Nothing needs to be done for a
|
||
borrowed reference.</p>
|
||
<p>Conversely, when a calling function passes in a reference to an object, there
|
||
are two possibilities: the function <em>steals</em> a reference to the object, or it
|
||
does not. <em>Stealing a reference</em> means that when you pass a reference to a
|
||
function, that function assumes that it now owns that reference, and you are not
|
||
responsible for it any longer.</p>
|
||
<p id="index-8">Few functions steal references; the two notable exceptions are
|
||
<a class="reference internal" href="list.html#c.PyList_SetItem" title="PyList_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyList_SetItem()</span></code></a> and <a class="reference internal" href="tuple.html#c.PyTuple_SetItem" title="PyTuple_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyTuple_SetItem()</span></code></a>, which steal a reference
|
||
to the item (but not to the tuple or list into which the item is put!). These
|
||
functions were designed to steal a reference because of a common idiom for
|
||
populating a tuple or list with newly created objects; for example, the code to
|
||
create the tuple <code class="docutils literal notranslate"><span class="pre">(1,</span> <span class="pre">2,</span> <span class="pre">"three")</span></code> could look like this (forgetting about
|
||
error handling for the moment; a better way to code this is shown below):</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="n">PyObject</span> <span class="o">*</span><span class="n">t</span><span class="p">;</span>
|
||
|
||
<span class="n">t</span> <span class="o">=</span> <span class="n">PyTuple_New</span><span class="p">(</span><span class="mi">3</span><span class="p">);</span>
|
||
<span class="n">PyTuple_SetItem</span><span class="p">(</span><span class="n">t</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="n">PyLong_FromLong</span><span class="p">(</span><span class="mi">1L</span><span class="p">));</span>
|
||
<span class="n">PyTuple_SetItem</span><span class="p">(</span><span class="n">t</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="n">PyLong_FromLong</span><span class="p">(</span><span class="mi">2L</span><span class="p">));</span>
|
||
<span class="n">PyTuple_SetItem</span><span class="p">(</span><span class="n">t</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="n">PyUnicode_FromString</span><span class="p">(</span><span class="s">"three"</span><span class="p">));</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Here, <a class="reference internal" href="long.html#c.PyLong_FromLong" title="PyLong_FromLong"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyLong_FromLong()</span></code></a> returns a new reference which is immediately
|
||
stolen by <a class="reference internal" href="tuple.html#c.PyTuple_SetItem" title="PyTuple_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyTuple_SetItem()</span></code></a>. When you want to keep using an object
|
||
although the reference to it will be stolen, use <a class="reference internal" href="refcounting.html#c.Py_INCREF" title="Py_INCREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_INCREF()</span></code></a> to grab
|
||
another reference before calling the reference-stealing function.</p>
|
||
<p>Incidentally, <a class="reference internal" href="tuple.html#c.PyTuple_SetItem" title="PyTuple_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyTuple_SetItem()</span></code></a> is the <em>only</em> way to set tuple items;
|
||
<a class="reference internal" href="sequence.html#c.PySequence_SetItem" title="PySequence_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PySequence_SetItem()</span></code></a> and <a class="reference internal" href="object.html#c.PyObject_SetItem" title="PyObject_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_SetItem()</span></code></a> refuse to do this
|
||
since tuples are an immutable data type. You should only use
|
||
<a class="reference internal" href="tuple.html#c.PyTuple_SetItem" title="PyTuple_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyTuple_SetItem()</span></code></a> for tuples that you are creating yourself.</p>
|
||
<p>Equivalent code for populating a list can be written using <a class="reference internal" href="list.html#c.PyList_New" title="PyList_New"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyList_New()</span></code></a>
|
||
and <a class="reference internal" href="list.html#c.PyList_SetItem" title="PyList_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyList_SetItem()</span></code></a>.</p>
|
||
<p>However, in practice, you will rarely use these ways of creating and populating
|
||
a tuple or list. There’s a generic function, <a class="reference internal" href="arg.html#c.Py_BuildValue" title="Py_BuildValue"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_BuildValue()</span></code></a>, that can
|
||
create most common objects from C values, directed by a <em class="dfn">format string</em>.
|
||
For example, the above two blocks of code could be replaced by the following
|
||
(which also takes care of the error checking):</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="n">PyObject</span> <span class="o">*</span><span class="n">tuple</span><span class="p">,</span> <span class="o">*</span><span class="n">list</span><span class="p">;</span>
|
||
|
||
<span class="n">tuple</span> <span class="o">=</span> <span class="n">Py_BuildValue</span><span class="p">(</span><span class="s">"(iis)"</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="s">"three"</span><span class="p">);</span>
|
||
<span class="n">list</span> <span class="o">=</span> <span class="n">Py_BuildValue</span><span class="p">(</span><span class="s">"[iis]"</span><span class="p">,</span> <span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="s">"three"</span><span class="p">);</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>It is much more common to use <a class="reference internal" href="object.html#c.PyObject_SetItem" title="PyObject_SetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_SetItem()</span></code></a> and friends with items
|
||
whose references you are only borrowing, like arguments that were passed in to
|
||
the function you are writing. In that case, their behaviour regarding reference
|
||
counts is much saner, since you don’t have to increment a reference count so you
|
||
can give a reference away (“have it be stolen”). For example, this function
|
||
sets all items of a list (actually, any mutable sequence) to a given item:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span>
|
||
<span class="nf">set_all</span><span class="p">(</span><span class="n">PyObject</span> <span class="o">*</span><span class="n">target</span><span class="p">,</span> <span class="n">PyObject</span> <span class="o">*</span><span class="n">item</span><span class="p">)</span>
|
||
<span class="p">{</span>
|
||
<span class="n">Py_ssize_t</span> <span class="n">i</span><span class="p">,</span> <span class="n">n</span><span class="p">;</span>
|
||
|
||
<span class="n">n</span> <span class="o">=</span> <span class="n">PyObject_Length</span><span class="p">(</span><span class="n">target</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">n</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
|
||
<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">PyObject</span> <span class="o">*</span><span class="n">index</span> <span class="o">=</span> <span class="n">PyLong_FromSsize_t</span><span class="p">(</span><span class="n">i</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">index</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">PyObject_SetItem</span><span class="p">(</span><span class="n">target</span><span class="p">,</span> <span class="n">index</span><span class="p">,</span> <span class="n">item</span><span class="p">)</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">Py_DECREF</span><span class="p">(</span><span class="n">index</span><span class="p">);</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="n">Py_DECREF</span><span class="p">(</span><span class="n">index</span><span class="p">);</span>
|
||
<span class="p">}</span>
|
||
<span class="k">return</span> <span class="mi">0</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<p id="index-9">The situation is slightly different for function return values. While passing
|
||
a reference to most functions does not change your ownership responsibilities
|
||
for that reference, many functions that return a reference to an object give
|
||
you ownership of the reference. The reason is simple: in many cases, the
|
||
returned object is created on the fly, and the reference you get is the only
|
||
reference to the object. Therefore, the generic functions that return object
|
||
references, like <a class="reference internal" href="object.html#c.PyObject_GetItem" title="PyObject_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GetItem()</span></code></a> and <a class="reference internal" href="sequence.html#c.PySequence_GetItem" title="PySequence_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PySequence_GetItem()</span></code></a>,
|
||
always return a new reference (the caller becomes the owner of the reference).</p>
|
||
<p>It is important to realize that whether you own a reference returned by a
|
||
function depends on which function you call only — <em>the plumage</em> (the type of
|
||
the object passed as an argument to the function) <em>doesn’t enter into it!</em>
|
||
Thus, if you extract an item from a list using <a class="reference internal" href="list.html#c.PyList_GetItem" title="PyList_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyList_GetItem()</span></code></a>, you
|
||
don’t own the reference — but if you obtain the same item from the same list
|
||
using <a class="reference internal" href="sequence.html#c.PySequence_GetItem" title="PySequence_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PySequence_GetItem()</span></code></a> (which happens to take exactly the same
|
||
arguments), you do own a reference to the returned object.</p>
|
||
<p id="index-10">Here is an example of how you could write a function that computes the sum of
|
||
the items in a list of integers; once using <a class="reference internal" href="list.html#c.PyList_GetItem" title="PyList_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyList_GetItem()</span></code></a>, and once
|
||
using <a class="reference internal" href="sequence.html#c.PySequence_GetItem" title="PySequence_GetItem"><code class="xref c c-func docutils literal notranslate"><span class="pre">PySequence_GetItem()</span></code></a>.</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">long</span>
|
||
<span class="nf">sum_list</span><span class="p">(</span><span class="n">PyObject</span> <span class="o">*</span><span class="n">list</span><span class="p">)</span>
|
||
<span class="p">{</span>
|
||
<span class="n">Py_ssize_t</span> <span class="n">i</span><span class="p">,</span> <span class="n">n</span><span class="p">;</span>
|
||
<span class="kt">long</span> <span class="n">total</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">value</span><span class="p">;</span>
|
||
<span class="n">PyObject</span> <span class="o">*</span><span class="n">item</span><span class="p">;</span>
|
||
|
||
<span class="n">n</span> <span class="o">=</span> <span class="n">PyList_Size</span><span class="p">(</span><span class="n">list</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">n</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span> <span class="cm">/* Not a list */</span>
|
||
<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">item</span> <span class="o">=</span> <span class="n">PyList_GetItem</span><span class="p">(</span><span class="n">list</span><span class="p">,</span> <span class="n">i</span><span class="p">);</span> <span class="cm">/* Can't fail */</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">PyLong_Check</span><span class="p">(</span><span class="n">item</span><span class="p">))</span> <span class="k">continue</span><span class="p">;</span> <span class="cm">/* Skip non-integers */</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">PyLong_AsLong</span><span class="p">(</span><span class="n">item</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">value</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span> <span class="o">&&</span> <span class="n">PyErr_Occurred</span><span class="p">())</span>
|
||
<span class="cm">/* Integer too big to fit in a C long, bail out */</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
|
||
<span class="n">total</span> <span class="o">+=</span> <span class="n">value</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="k">return</span> <span class="n">total</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<div class="highlight-c notranslate" id="index-11"><div class="highlight"><pre><span></span><span class="kt">long</span>
|
||
<span class="nf">sum_sequence</span><span class="p">(</span><span class="n">PyObject</span> <span class="o">*</span><span class="n">sequence</span><span class="p">)</span>
|
||
<span class="p">{</span>
|
||
<span class="n">Py_ssize_t</span> <span class="n">i</span><span class="p">,</span> <span class="n">n</span><span class="p">;</span>
|
||
<span class="kt">long</span> <span class="n">total</span> <span class="o">=</span> <span class="mi">0</span><span class="p">,</span> <span class="n">value</span><span class="p">;</span>
|
||
<span class="n">PyObject</span> <span class="o">*</span><span class="n">item</span><span class="p">;</span>
|
||
<span class="n">n</span> <span class="o">=</span> <span class="n">PySequence_Length</span><span class="p">(</span><span class="n">sequence</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">n</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span> <span class="cm">/* Has no length */</span>
|
||
<span class="k">for</span> <span class="p">(</span><span class="n">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="n">i</span> <span class="o"><</span> <span class="n">n</span><span class="p">;</span> <span class="n">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="n">item</span> <span class="o">=</span> <span class="n">PySequence_GetItem</span><span class="p">(</span><span class="n">sequence</span><span class="p">,</span> <span class="n">i</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">item</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span> <span class="cm">/* Not a sequence, or other failure */</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">PyLong_Check</span><span class="p">(</span><span class="n">item</span><span class="p">))</span> <span class="p">{</span>
|
||
<span class="n">value</span> <span class="o">=</span> <span class="n">PyLong_AsLong</span><span class="p">(</span><span class="n">item</span><span class="p">);</span>
|
||
<span class="n">Py_DECREF</span><span class="p">(</span><span class="n">item</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">value</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span> <span class="o">&&</span> <span class="n">PyErr_Occurred</span><span class="p">())</span>
|
||
<span class="cm">/* Integer too big to fit in a C long, bail out */</span>
|
||
<span class="k">return</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
|
||
<span class="n">total</span> <span class="o">+=</span> <span class="n">value</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="k">else</span> <span class="p">{</span>
|
||
<span class="n">Py_DECREF</span><span class="p">(</span><span class="n">item</span><span class="p">);</span> <span class="cm">/* Discard reference ownership */</span>
|
||
<span class="p">}</span>
|
||
<span class="p">}</span>
|
||
<span class="k">return</span> <span class="n">total</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="types">
|
||
<span id="api-types"></span><span id="index-12"></span><h3>Types<a class="headerlink" href="#types" title="Permalink to this headline">¶</a></h3>
|
||
<p>There are few other data types that play a significant role in the Python/C
|
||
API; most are simple C types such as <code class="xref c c-type docutils literal notranslate"><span class="pre">int</span></code>, <code class="xref c c-type docutils literal notranslate"><span class="pre">long</span></code>,
|
||
<code class="xref c c-type docutils literal notranslate"><span class="pre">double</span></code> and <code class="xref c c-type docutils literal notranslate"><span class="pre">char*</span></code>. A few structure types are used to
|
||
describe static tables used to list the functions exported by a module or the
|
||
data attributes of a new object type, and another is used to describe the value
|
||
of a complex number. These will be discussed together with the functions that
|
||
use them.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="exceptions">
|
||
<span id="api-exceptions"></span><h2>Exceptions<a class="headerlink" href="#exceptions" title="Permalink to this headline">¶</a></h2>
|
||
<p>The Python programmer only needs to deal with exceptions if specific error
|
||
handling is required; unhandled exceptions are automatically propagated to the
|
||
caller, then to the caller’s caller, and so on, until they reach the top-level
|
||
interpreter, where they are reported to the user accompanied by a stack
|
||
traceback.</p>
|
||
<p id="index-13">For C programmers, however, error checking always has to be explicit. All
|
||
functions in the Python/C API can raise exceptions, unless an explicit claim is
|
||
made otherwise in a function’s documentation. In general, when a function
|
||
encounters an error, it sets an exception, discards any object references that
|
||
it owns, and returns an error indicator. If not documented otherwise, this
|
||
indicator is either <em>NULL</em> or <code class="docutils literal notranslate"><span class="pre">-1</span></code>, depending on the function’s return type.
|
||
A few functions return a Boolean true/false result, with false indicating an
|
||
error. Very few functions return no explicit error indicator or have an
|
||
ambiguous return value, and require explicit testing for errors with
|
||
<a class="reference internal" href="exceptions.html#c.PyErr_Occurred" title="PyErr_Occurred"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_Occurred()</span></code></a>. These exceptions are always explicitly documented.</p>
|
||
<p id="index-14">Exception state is maintained in per-thread storage (this is equivalent to
|
||
using global storage in an unthreaded application). A thread can be in one of
|
||
two states: an exception has occurred, or not. The function
|
||
<a class="reference internal" href="exceptions.html#c.PyErr_Occurred" title="PyErr_Occurred"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_Occurred()</span></code></a> can be used to check for this: it returns a borrowed
|
||
reference to the exception type object when an exception has occurred, and
|
||
<em>NULL</em> otherwise. There are a number of functions to set the exception state:
|
||
<a class="reference internal" href="exceptions.html#c.PyErr_SetString" title="PyErr_SetString"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_SetString()</span></code></a> is the most common (though not the most general)
|
||
function to set the exception state, and <a class="reference internal" href="exceptions.html#c.PyErr_Clear" title="PyErr_Clear"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_Clear()</span></code></a> clears the
|
||
exception state.</p>
|
||
<p>The full exception state consists of three objects (all of which can be
|
||
<em>NULL</em>): the exception type, the corresponding exception value, and the
|
||
traceback. These have the same meanings as the Python result of
|
||
<code class="docutils literal notranslate"><span class="pre">sys.exc_info()</span></code>; however, they are not the same: the Python objects represent
|
||
the last exception being handled by a Python <a class="reference internal" href="../reference/compound_stmts.html#try"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">try</span></code></a> …
|
||
<a class="reference internal" href="../reference/compound_stmts.html#except"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">except</span></code></a> statement, while the C level exception state only exists while
|
||
an exception is being passed on between C functions until it reaches the Python
|
||
bytecode interpreter’s main loop, which takes care of transferring it to
|
||
<code class="docutils literal notranslate"><span class="pre">sys.exc_info()</span></code> and friends.</p>
|
||
<p id="index-15">Note that starting with Python 1.5, the preferred, thread-safe way to access the
|
||
exception state from Python code is to call the function <a class="reference internal" href="../library/sys.html#sys.exc_info" title="sys.exc_info"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.exc_info()</span></code></a>,
|
||
which returns the per-thread exception state for Python code. Also, the
|
||
semantics of both ways to access the exception state have changed so that a
|
||
function which catches an exception will save and restore its thread’s exception
|
||
state so as to preserve the exception state of its caller. This prevents common
|
||
bugs in exception handling code caused by an innocent-looking function
|
||
overwriting the exception being handled; it also reduces the often unwanted
|
||
lifetime extension for objects that are referenced by the stack frames in the
|
||
traceback.</p>
|
||
<p>As a general principle, a function that calls another function to perform some
|
||
task should check whether the called function raised an exception, and if so,
|
||
pass the exception state on to its caller. It should discard any object
|
||
references that it owns, and return an error indicator, but it should <em>not</em> set
|
||
another exception — that would overwrite the exception that was just raised,
|
||
and lose important information about the exact cause of the error.</p>
|
||
<p id="index-16">A simple example of detecting exceptions and passing them on is shown in the
|
||
<code class="xref c c-func docutils literal notranslate"><span class="pre">sum_sequence()</span></code> example above. It so happens that this example doesn’t
|
||
need to clean up any owned references when it detects an error. The following
|
||
example function shows some error cleanup. First, to remind you why you like
|
||
Python, we show the equivalent Python code:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="n">def</span> <span class="n">incr_item</span><span class="p">(</span><span class="n">dict</span><span class="p">,</span> <span class="n">key</span><span class="p">)</span><span class="o">:</span>
|
||
<span class="nl">try</span><span class="p">:</span>
|
||
<span class="n">item</span> <span class="o">=</span> <span class="n">dict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
<span class="n">except</span> <span class="nl">KeyError</span><span class="p">:</span>
|
||
<span class="n">item</span> <span class="o">=</span> <span class="mi">0</span>
|
||
<span class="n">dict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span> <span class="o">=</span> <span class="n">item</span> <span class="o">+</span> <span class="mi">1</span>
|
||
</pre></div>
|
||
</div>
|
||
<p id="index-17">Here is the corresponding C code, in all its glory:</p>
|
||
<div class="highlight-c notranslate"><div class="highlight"><pre><span></span><span class="kt">int</span>
|
||
<span class="nf">incr_item</span><span class="p">(</span><span class="n">PyObject</span> <span class="o">*</span><span class="n">dict</span><span class="p">,</span> <span class="n">PyObject</span> <span class="o">*</span><span class="n">key</span><span class="p">)</span>
|
||
<span class="p">{</span>
|
||
<span class="cm">/* Objects all initialized to NULL for Py_XDECREF */</span>
|
||
<span class="n">PyObject</span> <span class="o">*</span><span class="n">item</span> <span class="o">=</span> <span class="nb">NULL</span><span class="p">,</span> <span class="o">*</span><span class="n">const_one</span> <span class="o">=</span> <span class="nb">NULL</span><span class="p">,</span> <span class="o">*</span><span class="n">incremented_item</span> <span class="o">=</span> <span class="nb">NULL</span><span class="p">;</span>
|
||
<span class="kt">int</span> <span class="n">rv</span> <span class="o">=</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span> <span class="cm">/* Return value initialized to -1 (failure) */</span>
|
||
|
||
<span class="n">item</span> <span class="o">=</span> <span class="n">PyObject_GetItem</span><span class="p">(</span><span class="n">dict</span><span class="p">,</span> <span class="n">key</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">item</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span> <span class="p">{</span>
|
||
<span class="cm">/* Handle KeyError only: */</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">PyErr_ExceptionMatches</span><span class="p">(</span><span class="n">PyExc_KeyError</span><span class="p">))</span>
|
||
<span class="k">goto</span> <span class="n">error</span><span class="p">;</span>
|
||
|
||
<span class="cm">/* Clear the error and use zero: */</span>
|
||
<span class="n">PyErr_Clear</span><span class="p">();</span>
|
||
<span class="n">item</span> <span class="o">=</span> <span class="n">PyLong_FromLong</span><span class="p">(</span><span class="mi">0L</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">item</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span>
|
||
<span class="k">goto</span> <span class="n">error</span><span class="p">;</span>
|
||
<span class="p">}</span>
|
||
<span class="n">const_one</span> <span class="o">=</span> <span class="n">PyLong_FromLong</span><span class="p">(</span><span class="mi">1L</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">const_one</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span>
|
||
<span class="k">goto</span> <span class="n">error</span><span class="p">;</span>
|
||
|
||
<span class="n">incremented_item</span> <span class="o">=</span> <span class="n">PyNumber_Add</span><span class="p">(</span><span class="n">item</span><span class="p">,</span> <span class="n">const_one</span><span class="p">);</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">incremented_item</span> <span class="o">==</span> <span class="nb">NULL</span><span class="p">)</span>
|
||
<span class="k">goto</span> <span class="n">error</span><span class="p">;</span>
|
||
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">PyObject_SetItem</span><span class="p">(</span><span class="n">dict</span><span class="p">,</span> <span class="n">key</span><span class="p">,</span> <span class="n">incremented_item</span><span class="p">)</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span>
|
||
<span class="k">goto</span> <span class="n">error</span><span class="p">;</span>
|
||
<span class="n">rv</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="cm">/* Success */</span>
|
||
<span class="cm">/* Continue with cleanup code */</span>
|
||
|
||
<span class="nl">error</span><span class="p">:</span>
|
||
<span class="cm">/* Cleanup code, shared by success and failure path */</span>
|
||
|
||
<span class="cm">/* Use Py_XDECREF() to ignore NULL references */</span>
|
||
<span class="n">Py_XDECREF</span><span class="p">(</span><span class="n">item</span><span class="p">);</span>
|
||
<span class="n">Py_XDECREF</span><span class="p">(</span><span class="n">const_one</span><span class="p">);</span>
|
||
<span class="n">Py_XDECREF</span><span class="p">(</span><span class="n">incremented_item</span><span class="p">);</span>
|
||
|
||
<span class="k">return</span> <span class="n">rv</span><span class="p">;</span> <span class="cm">/* -1 for error, 0 for success */</span>
|
||
<span class="p">}</span>
|
||
</pre></div>
|
||
</div>
|
||
<span class="target" id="index-18"></span><p id="index-19">This example represents an endorsed use of the <code class="docutils literal notranslate"><span class="pre">goto</span></code> statement in C!
|
||
It illustrates the use of <a class="reference internal" href="exceptions.html#c.PyErr_ExceptionMatches" title="PyErr_ExceptionMatches"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_ExceptionMatches()</span></code></a> and
|
||
<a class="reference internal" href="exceptions.html#c.PyErr_Clear" title="PyErr_Clear"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyErr_Clear()</span></code></a> to handle specific exceptions, and the use of
|
||
<a class="reference internal" href="refcounting.html#c.Py_XDECREF" title="Py_XDECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_XDECREF()</span></code></a> to dispose of owned references that may be <em>NULL</em> (note the
|
||
<code class="docutils literal notranslate"><span class="pre">'X'</span></code> in the name; <a class="reference internal" href="refcounting.html#c.Py_DECREF" title="Py_DECREF"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_DECREF()</span></code></a> would crash when confronted with a
|
||
<em>NULL</em> reference). It is important that the variables used to hold owned
|
||
references are initialized to <em>NULL</em> for this to work; likewise, the proposed
|
||
return value is initialized to <code class="docutils literal notranslate"><span class="pre">-1</span></code> (failure) and only set to success after
|
||
the final call made is successful.</p>
|
||
</div>
|
||
<div class="section" id="embedding-python">
|
||
<span id="api-embedding"></span><h2>Embedding Python<a class="headerlink" href="#embedding-python" title="Permalink to this headline">¶</a></h2>
|
||
<p>The one important task that only embedders (as opposed to extension writers) of
|
||
the Python interpreter have to worry about is the initialization, and possibly
|
||
the finalization, of the Python interpreter. Most functionality of the
|
||
interpreter can only be used after the interpreter has been initialized.</p>
|
||
<p id="index-20">The basic initialization function is <a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a>. This initializes
|
||
the table of loaded modules, and creates the fundamental modules
|
||
<a class="reference internal" href="../library/builtins.html#module-builtins" title="builtins: The module that provides the built-in namespace."><code class="xref py py-mod docutils literal notranslate"><span class="pre">builtins</span></code></a>, <a class="reference internal" href="../library/__main__.html#module-__main__" title="__main__: The environment where the top-level script is run."><code class="xref py py-mod docutils literal notranslate"><span class="pre">__main__</span></code></a>, and <a class="reference internal" href="../library/sys.html#module-sys" title="sys: Access system-specific parameters and functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">sys</span></code></a>. It also
|
||
initializes the module search path (<code class="docutils literal notranslate"><span class="pre">sys.path</span></code>).</p>
|
||
<p id="index-21"><a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a> does not set the “script argument list” (<code class="docutils literal notranslate"><span class="pre">sys.argv</span></code>).
|
||
If this variable is needed by Python code that will be executed later, it must
|
||
be set explicitly with a call to <code class="docutils literal notranslate"><span class="pre">PySys_SetArgvEx(argc,</span> <span class="pre">argv,</span> <span class="pre">updatepath)</span></code>
|
||
after the call to <a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a>.</p>
|
||
<p>On most systems (in particular, on Unix and Windows, although the details are
|
||
slightly different), <a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a> calculates the module search path
|
||
based upon its best guess for the location of the standard Python interpreter
|
||
executable, assuming that the Python library is found in a fixed location
|
||
relative to the Python interpreter executable. In particular, it looks for a
|
||
directory named <code class="file docutils literal notranslate"><span class="pre">lib/python</span><em><span class="pre">X.Y</span></em></code> relative to the parent directory
|
||
where the executable named <code class="file docutils literal notranslate"><span class="pre">python</span></code> is found on the shell command search
|
||
path (the environment variable <span class="target" id="index-22"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PATH</span></code>).</p>
|
||
<p>For instance, if the Python executable is found in
|
||
<code class="file docutils literal notranslate"><span class="pre">/usr/local/bin/python</span></code>, it will assume that the libraries are in
|
||
<code class="file docutils literal notranslate"><span class="pre">/usr/local/lib/python</span><em><span class="pre">X.Y</span></em></code>. (In fact, this particular path is also
|
||
the “fallback” location, used when no executable file named <code class="file docutils literal notranslate"><span class="pre">python</span></code> is
|
||
found along <span class="target" id="index-23"></span><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PATH</span></code>.) The user can override this behavior by setting the
|
||
environment variable <span class="target" id="index-24"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONHOME"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PYTHONHOME</span></code></a>, or insert additional directories in
|
||
front of the standard path by setting <span class="target" id="index-25"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONPATH"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PYTHONPATH</span></code></a>.</p>
|
||
<p id="index-26">The embedding application can steer the search by calling
|
||
<code class="docutils literal notranslate"><span class="pre">Py_SetProgramName(file)</span></code> <em>before</em> calling <a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a>. Note that
|
||
<span class="target" id="index-27"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONHOME"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PYTHONHOME</span></code></a> still overrides this and <span class="target" id="index-28"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONPATH"><code class="xref std std-envvar docutils literal notranslate"><span class="pre">PYTHONPATH</span></code></a> is still
|
||
inserted in front of the standard path. An application that requires total
|
||
control has to provide its own implementation of <a class="reference internal" href="init.html#c.Py_GetPath" title="Py_GetPath"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_GetPath()</span></code></a>,
|
||
<a class="reference internal" href="init.html#c.Py_GetPrefix" title="Py_GetPrefix"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_GetPrefix()</span></code></a>, <a class="reference internal" href="init.html#c.Py_GetExecPrefix" title="Py_GetExecPrefix"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_GetExecPrefix()</span></code></a>, and
|
||
<a class="reference internal" href="init.html#c.Py_GetProgramFullPath" title="Py_GetProgramFullPath"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_GetProgramFullPath()</span></code></a> (all defined in <code class="file docutils literal notranslate"><span class="pre">Modules/getpath.c</span></code>).</p>
|
||
<p id="index-29">Sometimes, it is desirable to “uninitialize” Python. For instance, the
|
||
application may want to start over (make another call to
|
||
<a class="reference internal" href="init.html#c.Py_Initialize" title="Py_Initialize"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_Initialize()</span></code></a>) or the application is simply done with its use of
|
||
Python and wants to free memory allocated by Python. This can be accomplished
|
||
by calling <a class="reference internal" href="init.html#c.Py_FinalizeEx" title="Py_FinalizeEx"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_FinalizeEx()</span></code></a>. The function <a class="reference internal" href="init.html#c.Py_IsInitialized" title="Py_IsInitialized"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_IsInitialized()</span></code></a> returns
|
||
true if Python is currently in the initialized state. More information about
|
||
these functions is given in a later chapter. Notice that <a class="reference internal" href="init.html#c.Py_FinalizeEx" title="Py_FinalizeEx"><code class="xref c c-func docutils literal notranslate"><span class="pre">Py_FinalizeEx()</span></code></a>
|
||
does <em>not</em> free all memory allocated by the Python interpreter, e.g. memory
|
||
allocated by extension modules currently cannot be released.</p>
|
||
</div>
|
||
<div class="section" id="debugging-builds">
|
||
<span id="api-debugging"></span><h2>Debugging Builds<a class="headerlink" href="#debugging-builds" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python can be built with several macros to enable extra checks of the
|
||
interpreter and extension modules. These checks tend to add a large amount of
|
||
overhead to the runtime so they are not enabled by default.</p>
|
||
<p>A full list of the various types of debugging builds is in the file
|
||
<code class="file docutils literal notranslate"><span class="pre">Misc/SpecialBuilds.txt</span></code> in the Python source distribution. Builds are
|
||
available that support tracing of reference counts, debugging the memory
|
||
allocator, or low-level profiling of the main interpreter loop. Only the most
|
||
frequently-used builds will be described in the remainder of this section.</p>
|
||
<p>Compiling the interpreter with the <code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_DEBUG</span></code> macro defined produces
|
||
what is generally meant by “a debug build” of Python. <code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_DEBUG</span></code> is
|
||
enabled in the Unix build by adding <code class="docutils literal notranslate"><span class="pre">--with-pydebug</span></code> to the
|
||
<code class="file docutils literal notranslate"><span class="pre">./configure</span></code> command. It is also implied by the presence of the
|
||
not-Python-specific <code class="xref c c-macro docutils literal notranslate"><span class="pre">_DEBUG</span></code> macro. When <code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_DEBUG</span></code> is enabled
|
||
in the Unix build, compiler optimization is disabled.</p>
|
||
<p>In addition to the reference count debugging described below, the following
|
||
extra checks are performed:</p>
|
||
<ul class="simple">
|
||
<li><p>Extra checks are added to the object allocator.</p></li>
|
||
<li><p>Extra checks are added to the parser and compiler.</p></li>
|
||
<li><p>Downcasts from wide types to narrow types are checked for loss of information.</p></li>
|
||
<li><p>A number of assertions are added to the dictionary and set implementations.
|
||
In addition, the set object acquires a <code class="xref py py-meth docutils literal notranslate"><span class="pre">test_c_api()</span></code> method.</p></li>
|
||
<li><p>Sanity checks of the input arguments are added to frame creation.</p></li>
|
||
<li><p>The storage for ints is initialized with a known invalid pattern to catch
|
||
reference to uninitialized digits.</p></li>
|
||
<li><p>Low-level tracing and extra exception checking are added to the runtime
|
||
virtual machine.</p></li>
|
||
<li><p>Extra checks are added to the memory arena implementation.</p></li>
|
||
<li><p>Extra debugging is added to the thread module.</p></li>
|
||
</ul>
|
||
<p>There may be additional checks not mentioned here.</p>
|
||
<p>Defining <code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_TRACE_REFS</span></code> enables reference tracing. When defined, a
|
||
circular doubly linked list of active objects is maintained by adding two extra
|
||
fields to every <a class="reference internal" href="structures.html#c.PyObject" title="PyObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyObject</span></code></a>. Total allocations are tracked as well. Upon
|
||
exit, all existing references are printed. (In interactive mode this happens
|
||
after every statement run by the interpreter.) Implied by <code class="xref c c-macro docutils literal notranslate"><span class="pre">Py_DEBUG</span></code>.</p>
|
||
<p>Please refer to <code class="file docutils literal notranslate"><span class="pre">Misc/SpecialBuilds.txt</span></code> in the Python source distribution
|
||
for more detailed information.</p>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
|
||
<div class="sphinxsidebarwrapper">
|
||
<h3><a href="../contents.html">Table of Contents</a></h3>
|
||
<ul>
|
||
<li><a class="reference internal" href="#">Introduction</a><ul>
|
||
<li><a class="reference internal" href="#coding-standards">Coding standards</a></li>
|
||
<li><a class="reference internal" href="#include-files">Include Files</a></li>
|
||
<li><a class="reference internal" href="#useful-macros">Useful macros</a></li>
|
||
<li><a class="reference internal" href="#objects-types-and-reference-counts">Objects, Types and Reference Counts</a><ul>
|
||
<li><a class="reference internal" href="#reference-counts">Reference Counts</a><ul>
|
||
<li><a class="reference internal" href="#reference-count-details">Reference Count Details</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#types">Types</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#exceptions">Exceptions</a></li>
|
||
<li><a class="reference internal" href="#embedding-python">Embedding Python</a></li>
|
||
<li><a class="reference internal" href="#debugging-builds">Debugging Builds</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="index.html"
|
||
title="previous chapter">Python/C API Reference Manual</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="stable.html"
|
||
title="next chapter">Stable Application Binary Interface</a></p>
|
||
<div role="note" aria-label="source link">
|
||
<h3>This Page</h3>
|
||
<ul class="this-page-menu">
|
||
<li><a href="../bugs.html">Report a Bug</a></li>
|
||
<li>
|
||
<a href="https://github.com/python/cpython/blob/3.7/Doc/c-api/intro.rst"
|
||
rel="nofollow">Show Source
|
||
</a>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="related" role="navigation" aria-label="related navigation">
|
||
<h3>Navigation</h3>
|
||
<ul>
|
||
<li class="right" style="margin-right: 10px">
|
||
<a href="../genindex.html" title="General Index"
|
||
>index</a></li>
|
||
<li class="right" >
|
||
<a href="../py-modindex.html" title="Python Module Index"
|
||
>modules</a> |</li>
|
||
<li class="right" >
|
||
<a href="stable.html" title="Stable Application Binary Interface"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="index.html" title="Python/C API Reference Manual"
|
||
>previous</a> |</li>
|
||
<li><img src="../_static/py.png" alt=""
|
||
style="vertical-align: middle; margin-top: -1px"/></li>
|
||
<li><a href="https://www.python.org/">Python</a> »</li>
|
||
<li>
|
||
<span class="language_switcher_placeholder">en</span>
|
||
<span class="version_switcher_placeholder">3.7.4</span>
|
||
<a href="../index.html">Documentation </a> »
|
||
</li>
|
||
|
||
<li class="nav-item nav-item-1"><a href="index.html" >Python/C API Reference Manual</a> »</li>
|
||
<li class="right">
|
||
|
||
|
||
<div class="inline-search" style="display: none" role="search">
|
||
<form class="inline-search" action="../search.html" method="get">
|
||
<input placeholder="Quick search" type="text" name="q" />
|
||
<input type="submit" value="Go" />
|
||
<input type="hidden" name="check_keywords" value="yes" />
|
||
<input type="hidden" name="area" value="default" />
|
||
</form>
|
||
</div>
|
||
<script type="text/javascript">$('.inline-search').show(0);</script>
|
||
|
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
<div class="footer">
|
||
© <a href="../copyright.html">Copyright</a> 2001-2019, Python Software Foundation.
|
||
<br />
|
||
The Python Software Foundation is a non-profit corporation.
|
||
<a href="https://www.python.org/psf/donations/">Please donate.</a>
|
||
<br />
|
||
Last updated on Jul 13, 2019.
|
||
<a href="../bugs.html">Found a bug</a>?
|
||
<br />
|
||
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 2.0.1.
|
||
</div>
|
||
|
||
</body>
|
||
</html> |