1224 lines
128 KiB
HTML
1224 lines
128 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<title>What’s New in Python 2.0 — 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="Changelog" href="changelog.html" />
|
||
<link rel="prev" title="What’s New in Python 2.1" href="2.1.html" />
|
||
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
|
||
<link rel="canonical" href="https://docs.python.org/3/whatsnew/2.0.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="changelog.html" title="Changelog"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="2.1.html" title="What’s New in Python 2.1"
|
||
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">What’s New in Python</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="what-s-new-in-python-2-0">
|
||
<h1>What’s New in Python 2.0<a class="headerlink" href="#what-s-new-in-python-2-0" title="Permalink to this headline">¶</a></h1>
|
||
<dl class="field-list simple">
|
||
<dt class="field-odd">Author</dt>
|
||
<dd class="field-odd"><p>A.M. Kuchling and Moshe Zadka</p>
|
||
</dd>
|
||
</dl>
|
||
<div class="section" id="introduction">
|
||
<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
|
||
<p>A new release of Python, version 2.0, was released on October 16, 2000. This
|
||
article covers the exciting new features in 2.0, highlights some other useful
|
||
changes, and points out a few incompatible changes that may require rewriting
|
||
code.</p>
|
||
<p>Python’s development never completely stops between releases, and a steady flow
|
||
of bug fixes and improvements are always being submitted. A host of minor fixes,
|
||
a few optimizations, additional docstrings, and better error messages went into
|
||
2.0; to list them all would be impossible, but they’re certainly significant.
|
||
Consult the publicly-available CVS logs if you want to see the full list. This
|
||
progress is due to the five developers working for PythonLabs are now getting
|
||
paid to spend their days fixing bugs, and also due to the improved communication
|
||
resulting from moving to SourceForge.</p>
|
||
</div>
|
||
<div class="section" id="what-about-python-1-6">
|
||
<h2>What About Python 1.6?<a class="headerlink" href="#what-about-python-1-6" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python 1.6 can be thought of as the Contractual Obligations Python release.
|
||
After the core development team left CNRI in May 2000, CNRI requested that a 1.6
|
||
release be created, containing all the work on Python that had been performed at
|
||
CNRI. Python 1.6 therefore represents the state of the CVS tree as of May 2000,
|
||
with the most significant new feature being Unicode support. Development
|
||
continued after May, of course, so the 1.6 tree received a few fixes to ensure
|
||
that it’s forward-compatible with Python 2.0. 1.6 is therefore part of Python’s
|
||
evolution, and not a side branch.</p>
|
||
<p>So, should you take much interest in Python 1.6? Probably not. The 1.6final
|
||
and 2.0beta1 releases were made on the same day (September 5, 2000), the plan
|
||
being to finalize Python 2.0 within a month or so. If you have applications to
|
||
maintain, there seems little point in breaking things by moving to 1.6, fixing
|
||
them, and then having another round of breakage within a month by moving to 2.0;
|
||
you’re better off just going straight to 2.0. Most of the really interesting
|
||
features described in this document are only in 2.0, because a lot of work was
|
||
done between May and September.</p>
|
||
</div>
|
||
<div class="section" id="new-development-process">
|
||
<h2>New Development Process<a class="headerlink" href="#new-development-process" title="Permalink to this headline">¶</a></h2>
|
||
<p>The most important change in Python 2.0 may not be to the code at all, but to
|
||
how Python is developed: in May 2000 the Python developers began using the tools
|
||
made available by SourceForge for storing source code, tracking bug reports,
|
||
and managing the queue of patch submissions. To report bugs or submit patches
|
||
for Python 2.0, use the bug tracking and patch manager tools available from
|
||
Python’s project page, located at <a class="reference external" href="https://sourceforge.net/projects/python/">https://sourceforge.net/projects/python/</a>.</p>
|
||
<p>The most important of the services now hosted at SourceForge is the Python CVS
|
||
tree, the version-controlled repository containing the source code for Python.
|
||
Previously, there were roughly 7 or so people who had write access to the CVS
|
||
tree, and all patches had to be inspected and checked in by one of the people on
|
||
this short list. Obviously, this wasn’t very scalable. By moving the CVS tree
|
||
to SourceForge, it became possible to grant write access to more people; as of
|
||
September 2000 there were 27 people able to check in changes, a fourfold
|
||
increase. This makes possible large-scale changes that wouldn’t be attempted if
|
||
they’d have to be filtered through the small group of core developers. For
|
||
example, one day Peter Schneider-Kamp took it into his head to drop K&R C
|
||
compatibility and convert the C source for Python to ANSI C. After getting
|
||
approval on the python-dev mailing list, he launched into a flurry of checkins
|
||
that lasted about a week, other developers joined in to help, and the job was
|
||
done. If there were only 5 people with write access, probably that task would
|
||
have been viewed as “nice, but not worth the time and effort needed” and it
|
||
would never have gotten done.</p>
|
||
<p>The shift to using SourceForge’s services has resulted in a remarkable increase
|
||
in the speed of development. Patches now get submitted, commented on, revised
|
||
by people other than the original submitter, and bounced back and forth between
|
||
people until the patch is deemed worth checking in. Bugs are tracked in one
|
||
central location and can be assigned to a specific person for fixing, and we can
|
||
count the number of open bugs to measure progress. This didn’t come without a
|
||
cost: developers now have more e-mail to deal with, more mailing lists to
|
||
follow, and special tools had to be written for the new environment. For
|
||
example, SourceForge sends default patch and bug notification e-mail messages
|
||
that are completely unhelpful, so Ka-Ping Yee wrote an HTML screen-scraper that
|
||
sends more useful messages.</p>
|
||
<p>The ease of adding code caused a few initial growing pains, such as code was
|
||
checked in before it was ready or without getting clear agreement from the
|
||
developer group. The approval process that has emerged is somewhat similar to
|
||
that used by the Apache group. Developers can vote +1, +0, -0, or -1 on a patch;
|
||
+1 and -1 denote acceptance or rejection, while +0 and -0 mean the developer is
|
||
mostly indifferent to the change, though with a slight positive or negative
|
||
slant. The most significant change from the Apache model is that the voting is
|
||
essentially advisory, letting Guido van Rossum, who has Benevolent Dictator For
|
||
Life status, know what the general opinion is. He can still ignore the result of
|
||
a vote, and approve or reject a change even if the community disagrees with him.</p>
|
||
<p>Producing an actual patch is the last step in adding a new feature, and is
|
||
usually easy compared to the earlier task of coming up with a good design.
|
||
Discussions of new features can often explode into lengthy mailing list threads,
|
||
making the discussion hard to follow, and no one can read every posting to
|
||
python-dev. Therefore, a relatively formal process has been set up to write
|
||
Python Enhancement Proposals (PEPs), modelled on the Internet RFC process. PEPs
|
||
are draft documents that describe a proposed new feature, and are continually
|
||
revised until the community reaches a consensus, either accepting or rejecting
|
||
the proposal. Quoting from the introduction to PEP 1, “PEP Purpose and
|
||
Guidelines”:</p>
|
||
<blockquote class="epigraph">
|
||
<div><p>PEP stands for Python Enhancement Proposal. A PEP is a design document
|
||
providing information to the Python community, or describing a new feature for
|
||
Python. The PEP should provide a concise technical specification of the feature
|
||
and a rationale for the feature.</p>
|
||
<p>We intend PEPs to be the primary mechanisms for proposing new features, for
|
||
collecting community input on an issue, and for documenting the design decisions
|
||
that have gone into Python. The PEP author is responsible for building
|
||
consensus within the community and documenting dissenting opinions.</p>
|
||
</div></blockquote>
|
||
<p>Read the rest of PEP 1 for the details of the PEP editorial process, style, and
|
||
format. PEPs are kept in the Python CVS tree on SourceForge, though they’re not
|
||
part of the Python 2.0 distribution, and are also available in HTML form from
|
||
<a class="reference external" href="https://www.python.org/dev/peps/">https://www.python.org/dev/peps/</a>. As of September 2000, there are 25 PEPS, ranging
|
||
from PEP 201, “Lockstep Iteration”, to PEP 225, “Elementwise/Objectwise
|
||
Operators”.</p>
|
||
</div>
|
||
<div class="section" id="unicode">
|
||
<h2>Unicode<a class="headerlink" href="#unicode" title="Permalink to this headline">¶</a></h2>
|
||
<p>The largest new feature in Python 2.0 is a new fundamental data type: Unicode
|
||
strings. Unicode uses 16-bit numbers to represent characters instead of the
|
||
8-bit number used by ASCII, meaning that 65,536 distinct characters can be
|
||
supported.</p>
|
||
<p>The final interface for Unicode support was arrived at through countless
|
||
often-stormy discussions on the python-dev mailing list, and mostly implemented by
|
||
Marc-André Lemburg, based on a Unicode string type implementation by Fredrik
|
||
Lundh. A detailed explanation of the interface was written up as <span class="target" id="index-0"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0100"><strong>PEP 100</strong></a>,
|
||
“Python Unicode Integration”. This article will simply cover the most
|
||
significant points about the Unicode interfaces.</p>
|
||
<p>In Python source code, Unicode strings are written as <code class="docutils literal notranslate"><span class="pre">u"string"</span></code>. Arbitrary
|
||
Unicode characters can be written using a new escape sequence, <code class="docutils literal notranslate"><span class="pre">\uHHHH</span></code>, where
|
||
<em>HHHH</em> is a 4-digit hexadecimal number from 0000 to FFFF. The existing
|
||
<code class="docutils literal notranslate"><span class="pre">\xHHHH</span></code> escape sequence can also be used, and octal escapes can be used for
|
||
characters up to U+01FF, which is represented by <code class="docutils literal notranslate"><span class="pre">\777</span></code>.</p>
|
||
<p>Unicode strings, just like regular strings, are an immutable sequence type.
|
||
They can be indexed and sliced, but not modified in place. Unicode strings have
|
||
an <code class="docutils literal notranslate"><span class="pre">encode(</span> <span class="pre">[encoding]</span> <span class="pre">)</span></code> method that returns an 8-bit string in the desired
|
||
encoding. Encodings are named by strings, such as <code class="docutils literal notranslate"><span class="pre">'ascii'</span></code>, <code class="docutils literal notranslate"><span class="pre">'utf-8'</span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre">'iso-8859-1'</span></code>, or whatever. A codec API is defined for implementing and
|
||
registering new encodings that are then available throughout a Python program.
|
||
If an encoding isn’t specified, the default encoding is usually 7-bit ASCII,
|
||
though it can be changed for your Python installation by calling the
|
||
<code class="docutils literal notranslate"><span class="pre">sys.setdefaultencoding(encoding)</span></code> function in a customized version of
|
||
<code class="file docutils literal notranslate"><span class="pre">site.py</span></code>.</p>
|
||
<p>Combining 8-bit and Unicode strings always coerces to Unicode, using the default
|
||
ASCII encoding; the result of <code class="docutils literal notranslate"><span class="pre">'a'</span> <span class="pre">+</span> <span class="pre">u'bc'</span></code> is <code class="docutils literal notranslate"><span class="pre">u'abc'</span></code>.</p>
|
||
<p>New built-in functions have been added, and existing built-ins modified to
|
||
support Unicode:</p>
|
||
<ul class="simple">
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">unichr(ch)</span></code> returns a Unicode string 1 character long, containing the
|
||
character <em>ch</em>.</p></li>
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">ord(u)</span></code>, where <em>u</em> is a 1-character regular or Unicode string, returns the
|
||
number of the character as an integer.</p></li>
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">unicode(string</span> <span class="pre">[,</span> <span class="pre">encoding]</span>  <span class="pre">[,</span> <span class="pre">errors]</span> <span class="pre">)</span></code> creates a Unicode string
|
||
from an 8-bit string. <code class="docutils literal notranslate"><span class="pre">encoding</span></code> is a string naming the encoding to use. The
|
||
<code class="docutils literal notranslate"><span class="pre">errors</span></code> parameter specifies the treatment of characters that are invalid for
|
||
the current encoding; passing <code class="docutils literal notranslate"><span class="pre">'strict'</span></code> as the value causes an exception to
|
||
be raised on any encoding error, while <code class="docutils literal notranslate"><span class="pre">'ignore'</span></code> causes errors to be silently
|
||
ignored and <code class="docutils literal notranslate"><span class="pre">'replace'</span></code> uses U+FFFD, the official replacement character, in
|
||
case of any problems.</p></li>
|
||
<li><p>The <code class="docutils literal notranslate"><span class="pre">exec</span></code> statement, and various built-ins such as <code class="docutils literal notranslate"><span class="pre">eval()</span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre">getattr()</span></code>, and <code class="docutils literal notranslate"><span class="pre">setattr()</span></code> will also accept Unicode strings as well as
|
||
regular strings. (It’s possible that the process of fixing this missed some
|
||
built-ins; if you find a built-in function that accepts strings but doesn’t
|
||
accept Unicode strings at all, please report it as a bug.)</p></li>
|
||
</ul>
|
||
<p>A new module, <a class="reference internal" href="../library/unicodedata.html#module-unicodedata" title="unicodedata: Access the Unicode Database."><code class="xref py py-mod docutils literal notranslate"><span class="pre">unicodedata</span></code></a>, provides an interface to Unicode character
|
||
properties. For example, <code class="docutils literal notranslate"><span class="pre">unicodedata.category(u'A')</span></code> returns the 2-character
|
||
string ‘Lu’, the ‘L’ denoting it’s a letter, and ‘u’ meaning that it’s
|
||
uppercase. <code class="docutils literal notranslate"><span class="pre">unicodedata.bidirectional(u'\u0660')</span></code> returns ‘AN’, meaning that
|
||
U+0660 is an Arabic number.</p>
|
||
<p>The <a class="reference internal" href="../library/codecs.html#module-codecs" title="codecs: Encode and decode data and streams."><code class="xref py py-mod docutils literal notranslate"><span class="pre">codecs</span></code></a> module contains functions to look up existing encodings and
|
||
register new ones. Unless you want to implement a new encoding, you’ll most
|
||
often use the <code class="docutils literal notranslate"><span class="pre">codecs.lookup(encoding)</span></code> function, which returns a
|
||
4-element tuple: <code class="docutils literal notranslate"><span class="pre">(encode_func,</span> <span class="pre">decode_func,</span> <span class="pre">stream_reader,</span> <span class="pre">stream_writer)</span></code>.</p>
|
||
<ul class="simple">
|
||
<li><p><em>encode_func</em> is a function that takes a Unicode string, and returns a 2-tuple
|
||
<code class="docutils literal notranslate"><span class="pre">(string,</span> <span class="pre">length)</span></code>. <em>string</em> is an 8-bit string containing a portion (perhaps
|
||
all) of the Unicode string converted into the given encoding, and <em>length</em> tells
|
||
you how much of the Unicode string was converted.</p></li>
|
||
<li><p><em>decode_func</em> is the opposite of <em>encode_func</em>, taking an 8-bit string and
|
||
returning a 2-tuple <code class="docutils literal notranslate"><span class="pre">(ustring,</span> <span class="pre">length)</span></code>, consisting of the resulting Unicode
|
||
string <em>ustring</em> and the integer <em>length</em> telling how much of the 8-bit string
|
||
was consumed.</p></li>
|
||
<li><p><em>stream_reader</em> is a class that supports decoding input from a stream.
|
||
<em>stream_reader(file_obj)</em> returns an object that supports the <code class="xref py py-meth docutils literal notranslate"><span class="pre">read()</span></code>,
|
||
<a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><code class="xref py py-meth docutils literal notranslate"><span class="pre">readline()</span></code></a>, and <code class="xref py py-meth docutils literal notranslate"><span class="pre">readlines()</span></code> methods. These methods will all
|
||
translate from the given encoding and return Unicode strings.</p></li>
|
||
<li><p><em>stream_writer</em>, similarly, is a class that supports encoding output to a
|
||
stream. <em>stream_writer(file_obj)</em> returns an object that supports the
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">write()</span></code> and <code class="xref py py-meth docutils literal notranslate"><span class="pre">writelines()</span></code> methods. These methods expect Unicode
|
||
strings, translating them to the given encoding on output.</p></li>
|
||
</ul>
|
||
<p>For example, the following code writes a Unicode string into a file, encoding
|
||
it as UTF-8:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">codecs</span>
|
||
|
||
<span class="n">unistr</span> <span class="o">=</span> <span class="sa">u</span><span class="s1">'</span><span class="se">\u0660\u2000</span><span class="s1">ab ...'</span>
|
||
|
||
<span class="p">(</span><span class="n">UTF8_encode</span><span class="p">,</span> <span class="n">UTF8_decode</span><span class="p">,</span>
|
||
<span class="n">UTF8_streamreader</span><span class="p">,</span> <span class="n">UTF8_streamwriter</span><span class="p">)</span> <span class="o">=</span> <span class="n">codecs</span><span class="o">.</span><span class="n">lookup</span><span class="p">(</span><span class="s1">'UTF-8'</span><span class="p">)</span>
|
||
|
||
<span class="n">output</span> <span class="o">=</span> <span class="n">UTF8_streamwriter</span><span class="p">(</span> <span class="nb">open</span><span class="p">(</span> <span class="s1">'/tmp/output'</span><span class="p">,</span> <span class="s1">'wb'</span><span class="p">)</span> <span class="p">)</span>
|
||
<span class="n">output</span><span class="o">.</span><span class="n">write</span><span class="p">(</span> <span class="n">unistr</span> <span class="p">)</span>
|
||
<span class="n">output</span><span class="o">.</span><span class="n">close</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The following code would then read UTF-8 input from the file:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="nb">input</span> <span class="o">=</span> <span class="n">UTF8_streamreader</span><span class="p">(</span> <span class="nb">open</span><span class="p">(</span> <span class="s1">'/tmp/output'</span><span class="p">,</span> <span class="s1">'rb'</span><span class="p">)</span> <span class="p">)</span>
|
||
<span class="nb">print</span> <span class="nb">repr</span><span class="p">(</span><span class="nb">input</span><span class="o">.</span><span class="n">read</span><span class="p">())</span>
|
||
<span class="nb">input</span><span class="o">.</span><span class="n">close</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Unicode-aware regular expressions are available through the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">re</span></code></a> module,
|
||
which has a new underlying implementation called SRE written by Fredrik Lundh of
|
||
Secret Labs AB.</p>
|
||
<p>A <code class="docutils literal notranslate"><span class="pre">-U</span></code> command line option was added which causes the Python compiler to
|
||
interpret all string literals as Unicode string literals. This is intended to be
|
||
used in testing and future-proofing your Python code, since some future version
|
||
of Python may drop support for 8-bit strings and provide only Unicode strings.</p>
|
||
</div>
|
||
<div class="section" id="list-comprehensions">
|
||
<h2>List Comprehensions<a class="headerlink" href="#list-comprehensions" title="Permalink to this headline">¶</a></h2>
|
||
<p>Lists are a workhorse data type in Python, and many programs manipulate a list
|
||
at some point. Two common operations on lists are to loop over them, and either
|
||
pick out the elements that meet a certain criterion, or apply some function to
|
||
each element. For example, given a list of strings, you might want to pull out
|
||
all the strings containing a given substring, or strip off trailing whitespace
|
||
from each line.</p>
|
||
<p>The existing <a class="reference internal" href="../library/functions.html#map" title="map"><code class="xref py py-func docutils literal notranslate"><span class="pre">map()</span></code></a> and <a class="reference internal" href="../library/functions.html#filter" title="filter"><code class="xref py py-func docutils literal notranslate"><span class="pre">filter()</span></code></a> functions can be used for this
|
||
purpose, but they require a function as one of their arguments. This is fine if
|
||
there’s an existing built-in function that can be passed directly, but if there
|
||
isn’t, you have to create a little function to do the required work, and
|
||
Python’s scoping rules make the result ugly if the little function needs
|
||
additional information. Take the first example in the previous paragraph,
|
||
finding all the strings in the list containing a given substring. You could
|
||
write the following to do it:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># Given the list L, make a list of all strings</span>
|
||
<span class="c1"># containing the substring S.</span>
|
||
<span class="n">sublist</span> <span class="o">=</span> <span class="nb">filter</span><span class="p">(</span> <span class="k">lambda</span> <span class="n">s</span><span class="p">,</span> <span class="n">substring</span><span class="o">=</span><span class="n">S</span><span class="p">:</span>
|
||
<span class="n">string</span><span class="o">.</span><span class="n">find</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">substring</span><span class="p">)</span> <span class="o">!=</span> <span class="o">-</span><span class="mi">1</span><span class="p">,</span>
|
||
<span class="n">L</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Because of Python’s scoping rules, a default argument is used so that the
|
||
anonymous function created by the <a class="reference internal" href="../reference/expressions.html#lambda"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">lambda</span></code></a> expression knows what
|
||
substring is being searched for. List comprehensions make this cleaner:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">sublist</span> <span class="o">=</span> <span class="p">[</span> <span class="n">s</span> <span class="k">for</span> <span class="n">s</span> <span class="ow">in</span> <span class="n">L</span> <span class="k">if</span> <span class="n">string</span><span class="o">.</span><span class="n">find</span><span class="p">(</span><span class="n">s</span><span class="p">,</span> <span class="n">S</span><span class="p">)</span> <span class="o">!=</span> <span class="o">-</span><span class="mi">1</span> <span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>List comprehensions have the form:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="p">[</span> <span class="n">expression</span> <span class="k">for</span> <span class="n">expr</span> <span class="ow">in</span> <span class="n">sequence1</span>
|
||
<span class="k">for</span> <span class="n">expr2</span> <span class="ow">in</span> <span class="n">sequence2</span> <span class="o">...</span>
|
||
<span class="k">for</span> <span class="n">exprN</span> <span class="ow">in</span> <span class="n">sequenceN</span>
|
||
<span class="k">if</span> <span class="n">condition</span> <span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="xref std std-keyword docutils literal notranslate"><span class="pre">for</span></code>…<code class="xref std std-keyword docutils literal notranslate"><span class="pre">in</span></code> clauses contain the sequences to be
|
||
iterated over. The sequences do not have to be the same length, because they
|
||
are <em>not</em> iterated over in parallel, but from left to right; this is explained
|
||
more clearly in the following paragraphs. The elements of the generated list
|
||
will be the successive values of <em>expression</em>. The final <code class="xref std std-keyword docutils literal notranslate"><span class="pre">if</span></code> clause
|
||
is optional; if present, <em>expression</em> is only evaluated and added to the result
|
||
if <em>condition</em> is true.</p>
|
||
<p>To make the semantics very clear, a list comprehension is equivalent to the
|
||
following Python code:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">expr1</span> <span class="ow">in</span> <span class="n">sequence1</span><span class="p">:</span>
|
||
<span class="k">for</span> <span class="n">expr2</span> <span class="ow">in</span> <span class="n">sequence2</span><span class="p">:</span>
|
||
<span class="o">...</span>
|
||
<span class="k">for</span> <span class="n">exprN</span> <span class="ow">in</span> <span class="n">sequenceN</span><span class="p">:</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">condition</span><span class="p">):</span>
|
||
<span class="c1"># Append the value of</span>
|
||
<span class="c1"># the expression to the</span>
|
||
<span class="c1"># resulting list.</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This means that when there are multiple <code class="xref std std-keyword docutils literal notranslate"><span class="pre">for</span></code>…<code class="xref std std-keyword docutils literal notranslate"><span class="pre">in</span></code>
|
||
clauses, the resulting list will be equal to the product of the lengths of all
|
||
the sequences. If you have two lists of length 3, the output list is 9 elements
|
||
long:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">seq1</span> <span class="o">=</span> <span class="s1">'abc'</span>
|
||
<span class="n">seq2</span> <span class="o">=</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="mi">3</span><span class="p">)</span>
|
||
<span class="o">>>></span> <span class="p">[</span> <span class="p">(</span><span class="n">x</span><span class="p">,</span><span class="n">y</span><span class="p">)</span> <span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="n">seq1</span> <span class="k">for</span> <span class="n">y</span> <span class="ow">in</span> <span class="n">seq2</span><span class="p">]</span>
|
||
<span class="p">[(</span><span class="s1">'a'</span><span class="p">,</span> <span class="mi">1</span><span class="p">),</span> <span class="p">(</span><span class="s1">'a'</span><span class="p">,</span> <span class="mi">2</span><span class="p">),</span> <span class="p">(</span><span class="s1">'a'</span><span class="p">,</span> <span class="mi">3</span><span class="p">),</span> <span class="p">(</span><span class="s1">'b'</span><span class="p">,</span> <span class="mi">1</span><span class="p">),</span> <span class="p">(</span><span class="s1">'b'</span><span class="p">,</span> <span class="mi">2</span><span class="p">),</span> <span class="p">(</span><span class="s1">'b'</span><span class="p">,</span> <span class="mi">3</span><span class="p">),</span> <span class="p">(</span><span class="s1">'c'</span><span class="p">,</span> <span class="mi">1</span><span class="p">),</span>
|
||
<span class="p">(</span><span class="s1">'c'</span><span class="p">,</span> <span class="mi">2</span><span class="p">),</span> <span class="p">(</span><span class="s1">'c'</span><span class="p">,</span> <span class="mi">3</span><span class="p">)]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>To avoid introducing an ambiguity into Python’s grammar, if <em>expression</em> is
|
||
creating a tuple, it must be surrounded with parentheses. The first list
|
||
comprehension below is a syntax error, while the second one is correct:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># Syntax error</span>
|
||
<span class="p">[</span> <span class="n">x</span><span class="p">,</span><span class="n">y</span> <span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="n">seq1</span> <span class="k">for</span> <span class="n">y</span> <span class="ow">in</span> <span class="n">seq2</span><span class="p">]</span>
|
||
<span class="c1"># Correct</span>
|
||
<span class="p">[</span> <span class="p">(</span><span class="n">x</span><span class="p">,</span><span class="n">y</span><span class="p">)</span> <span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="n">seq1</span> <span class="k">for</span> <span class="n">y</span> <span class="ow">in</span> <span class="n">seq2</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The idea of list comprehensions originally comes from the functional programming
|
||
language Haskell (<a class="reference external" href="https://www.haskell.org">https://www.haskell.org</a>). Greg Ewing argued most effectively
|
||
for adding them to Python and wrote the initial list comprehension patch, which
|
||
was then discussed for a seemingly endless time on the python-dev mailing list
|
||
and kept up-to-date by Skip Montanaro.</p>
|
||
</div>
|
||
<div class="section" id="augmented-assignment">
|
||
<h2>Augmented Assignment<a class="headerlink" href="#augmented-assignment" title="Permalink to this headline">¶</a></h2>
|
||
<p>Augmented assignment operators, another long-requested feature, have been added
|
||
to Python 2.0. Augmented assignment operators include <code class="docutils literal notranslate"><span class="pre">+=</span></code>, <code class="docutils literal notranslate"><span class="pre">-=</span></code>, <code class="docutils literal notranslate"><span class="pre">*=</span></code>,
|
||
and so forth. For example, the statement <code class="docutils literal notranslate"><span class="pre">a</span> <span class="pre">+=</span> <span class="pre">2</span></code> increments the value of the
|
||
variable <code class="docutils literal notranslate"><span class="pre">a</span></code> by 2, equivalent to the slightly lengthier <code class="docutils literal notranslate"><span class="pre">a</span> <span class="pre">=</span> <span class="pre">a</span> <span class="pre">+</span> <span class="pre">2</span></code>.</p>
|
||
<p>The full list of supported assignment operators is <code class="docutils literal notranslate"><span class="pre">+=</span></code>, <code class="docutils literal notranslate"><span class="pre">-=</span></code>, <code class="docutils literal notranslate"><span class="pre">*=</span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre">/=</span></code>, <code class="docutils literal notranslate"><span class="pre">%=</span></code>, <code class="docutils literal notranslate"><span class="pre">**=</span></code>, <code class="docutils literal notranslate"><span class="pre">&=</span></code>, <code class="docutils literal notranslate"><span class="pre">|=</span></code>, <code class="docutils literal notranslate"><span class="pre">^=</span></code>, <code class="docutils literal notranslate"><span class="pre">>>=</span></code>, and <code class="docutils literal notranslate"><span class="pre"><<=</span></code>. Python
|
||
classes can override the augmented assignment operators by defining methods
|
||
named <a class="reference internal" href="../reference/datamodel.html#object.__iadd__" title="object.__iadd__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__iadd__()</span></code></a>, <a class="reference internal" href="../reference/datamodel.html#object.__isub__" title="object.__isub__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__isub__()</span></code></a>, etc. For example, the following
|
||
<code class="xref py py-class docutils literal notranslate"><span class="pre">Number</span></code> class stores a number and supports using += to create a new
|
||
instance with an incremented value.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">Number</span><span class="p">:</span>
|
||
<span class="k">def</span> <span class="nf">__init__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">value</span><span class="p">):</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">value</span> <span class="o">=</span> <span class="n">value</span>
|
||
<span class="k">def</span> <span class="nf">__iadd__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">increment</span><span class="p">):</span>
|
||
<span class="k">return</span> <span class="n">Number</span><span class="p">(</span> <span class="bp">self</span><span class="o">.</span><span class="n">value</span> <span class="o">+</span> <span class="n">increment</span><span class="p">)</span>
|
||
|
||
<span class="n">n</span> <span class="o">=</span> <span class="n">Number</span><span class="p">(</span><span class="mi">5</span><span class="p">)</span>
|
||
<span class="n">n</span> <span class="o">+=</span> <span class="mi">3</span>
|
||
<span class="nb">print</span> <span class="n">n</span><span class="o">.</span><span class="n">value</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <a class="reference internal" href="../reference/datamodel.html#object.__iadd__" title="object.__iadd__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__iadd__()</span></code></a> special method is called with the value of the increment,
|
||
and should return a new instance with an appropriately modified value; this
|
||
return value is bound as the new value of the variable on the left-hand side.</p>
|
||
<p>Augmented assignment operators were first introduced in the C programming
|
||
language, and most C-derived languages, such as <strong class="program">awk</strong>, C++, Java, Perl,
|
||
and PHP also support them. The augmented assignment patch was implemented by
|
||
Thomas Wouters.</p>
|
||
</div>
|
||
<div class="section" id="string-methods">
|
||
<h2>String Methods<a class="headerlink" href="#string-methods" title="Permalink to this headline">¶</a></h2>
|
||
<p>Until now string-manipulation functionality was in the <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">string</span></code></a> module,
|
||
which was usually a front-end for the <code class="xref py py-mod docutils literal notranslate"><span class="pre">strop</span></code> module written in C. The
|
||
addition of Unicode posed a difficulty for the <code class="xref py py-mod docutils literal notranslate"><span class="pre">strop</span></code> module, because the
|
||
functions would all need to be rewritten in order to accept either 8-bit or
|
||
Unicode strings. For functions such as <code class="xref py py-func docutils literal notranslate"><span class="pre">string.replace()</span></code>, which takes 3
|
||
string arguments, that means eight possible permutations, and correspondingly
|
||
complicated code.</p>
|
||
<p>Instead, Python 2.0 pushes the problem onto the string type, making string
|
||
manipulation functionality available through methods on both 8-bit strings and
|
||
Unicode strings.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="s1">'andrew'</span><span class="o">.</span><span class="n">capitalize</span><span class="p">()</span>
|
||
<span class="go">'Andrew'</span>
|
||
<span class="gp">>>> </span><span class="s1">'hostname'</span><span class="o">.</span><span class="n">replace</span><span class="p">(</span><span class="s1">'os'</span><span class="p">,</span> <span class="s1">'linux'</span><span class="p">)</span>
|
||
<span class="go">'hlinuxtname'</span>
|
||
<span class="gp">>>> </span><span class="s1">'moshe'</span><span class="o">.</span><span class="n">find</span><span class="p">(</span><span class="s1">'sh'</span><span class="p">)</span>
|
||
<span class="go">2</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>One thing that hasn’t changed, a noteworthy April Fools’ joke notwithstanding,
|
||
is that Python strings are immutable. Thus, the string methods return new
|
||
strings, and do not modify the string on which they operate.</p>
|
||
<p>The old <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">string</span></code></a> module is still around for backwards compatibility, but it
|
||
mostly acts as a front-end to the new string methods.</p>
|
||
<p>Two methods which have no parallel in pre-2.0 versions, although they did exist
|
||
in JPython for quite some time, are <code class="xref py py-meth docutils literal notranslate"><span class="pre">startswith()</span></code> and <code class="xref py py-meth docutils literal notranslate"><span class="pre">endswith()</span></code>.
|
||
<code class="docutils literal notranslate"><span class="pre">s.startswith(t)</span></code> is equivalent to <code class="docutils literal notranslate"><span class="pre">s[:len(t)]</span> <span class="pre">==</span> <span class="pre">t</span></code>, while
|
||
<code class="docutils literal notranslate"><span class="pre">s.endswith(t)</span></code> is equivalent to <code class="docutils literal notranslate"><span class="pre">s[-len(t):]</span> <span class="pre">==</span> <span class="pre">t</span></code>.</p>
|
||
<p>One other method which deserves special mention is <code class="xref py py-meth docutils literal notranslate"><span class="pre">join()</span></code>. The
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">join()</span></code> method of a string receives one parameter, a sequence of strings,
|
||
and is equivalent to the <code class="xref py py-func docutils literal notranslate"><span class="pre">string.join()</span></code> function from the old <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">string</span></code></a>
|
||
module, with the arguments reversed. In other words, <code class="docutils literal notranslate"><span class="pre">s.join(seq)</span></code> is
|
||
equivalent to the old <code class="docutils literal notranslate"><span class="pre">string.join(seq,</span> <span class="pre">s)</span></code>.</p>
|
||
</div>
|
||
<div class="section" id="garbage-collection-of-cycles">
|
||
<h2>Garbage Collection of Cycles<a class="headerlink" href="#garbage-collection-of-cycles" title="Permalink to this headline">¶</a></h2>
|
||
<p>The C implementation of Python uses reference counting to implement garbage
|
||
collection. Every Python object maintains a count of the number of references
|
||
pointing to itself, and adjusts the count as references are created or
|
||
destroyed. Once the reference count reaches zero, the object is no longer
|
||
accessible, since you need to have a reference to an object to access it, and if
|
||
the count is zero, no references exist any longer.</p>
|
||
<p>Reference counting has some pleasant properties: it’s easy to understand and
|
||
implement, and the resulting implementation is portable, fairly fast, and reacts
|
||
well with other libraries that implement their own memory handling schemes. The
|
||
major problem with reference counting is that it sometimes doesn’t realise that
|
||
objects are no longer accessible, resulting in a memory leak. This happens when
|
||
there are cycles of references.</p>
|
||
<p>Consider the simplest possible cycle, a class instance which has a reference to
|
||
itself:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">instance</span> <span class="o">=</span> <span class="n">SomeClass</span><span class="p">()</span>
|
||
<span class="n">instance</span><span class="o">.</span><span class="n">myself</span> <span class="o">=</span> <span class="n">instance</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>After the above two lines of code have been executed, the reference count of
|
||
<code class="docutils literal notranslate"><span class="pre">instance</span></code> is 2; one reference is from the variable named <code class="docutils literal notranslate"><span class="pre">'instance'</span></code>, and
|
||
the other is from the <code class="docutils literal notranslate"><span class="pre">myself</span></code> attribute of the instance.</p>
|
||
<p>If the next line of code is <code class="docutils literal notranslate"><span class="pre">del</span> <span class="pre">instance</span></code>, what happens? The reference count
|
||
of <code class="docutils literal notranslate"><span class="pre">instance</span></code> is decreased by 1, so it has a reference count of 1; the
|
||
reference in the <code class="docutils literal notranslate"><span class="pre">myself</span></code> attribute still exists. Yet the instance is no
|
||
longer accessible through Python code, and it could be deleted. Several objects
|
||
can participate in a cycle if they have references to each other, causing all of
|
||
the objects to be leaked.</p>
|
||
<p>Python 2.0 fixes this problem by periodically executing a cycle detection
|
||
algorithm which looks for inaccessible cycles and deletes the objects involved.
|
||
A new <a class="reference internal" href="../library/gc.html#module-gc" title="gc: Interface to the cycle-detecting garbage collector."><code class="xref py py-mod docutils literal notranslate"><span class="pre">gc</span></code></a> module provides functions to perform a garbage collection,
|
||
obtain debugging statistics, and tuning the collector’s parameters.</p>
|
||
<p>Running the cycle detection algorithm takes some time, and therefore will result
|
||
in some additional overhead. It is hoped that after we’ve gotten experience
|
||
with the cycle collection from using 2.0, Python 2.1 will be able to minimize
|
||
the overhead with careful tuning. It’s not yet obvious how much performance is
|
||
lost, because benchmarking this is tricky and depends crucially on how often the
|
||
program creates and destroys objects. The detection of cycles can be disabled
|
||
when Python is compiled, if you can’t afford even a tiny speed penalty or
|
||
suspect that the cycle collection is buggy, by specifying the
|
||
<code class="xref std std-option docutils literal notranslate"><span class="pre">--without-cycle-gc</span></code> switch when running the <strong class="program">configure</strong>
|
||
script.</p>
|
||
<p>Several people tackled this problem and contributed to a solution. An early
|
||
implementation of the cycle detection approach was written by Toby Kelsey. The
|
||
current algorithm was suggested by Eric Tiedemann during a visit to CNRI, and
|
||
Guido van Rossum and Neil Schemenauer wrote two different implementations, which
|
||
were later integrated by Neil. Lots of other people offered suggestions along
|
||
the way; the March 2000 archives of the python-dev mailing list contain most of
|
||
the relevant discussion, especially in the threads titled “Reference cycle
|
||
collection for Python” and “Finalization again”.</p>
|
||
</div>
|
||
<div class="section" id="other-core-changes">
|
||
<h2>Other Core Changes<a class="headerlink" href="#other-core-changes" title="Permalink to this headline">¶</a></h2>
|
||
<p>Various minor changes have been made to Python’s syntax and built-in functions.
|
||
None of the changes are very far-reaching, but they’re handy conveniences.</p>
|
||
<div class="section" id="minor-language-changes">
|
||
<h3>Minor Language Changes<a class="headerlink" href="#minor-language-changes" title="Permalink to this headline">¶</a></h3>
|
||
<p>A new syntax makes it more convenient to call a given function with a tuple of
|
||
arguments and/or a dictionary of keyword arguments. In Python 1.5 and earlier,
|
||
you’d use the <code class="xref py py-func docutils literal notranslate"><span class="pre">apply()</span></code> built-in function: <code class="docutils literal notranslate"><span class="pre">apply(f,</span> <span class="pre">args,</span> <span class="pre">kw)</span></code> calls the
|
||
function <code class="xref py py-func docutils literal notranslate"><span class="pre">f()</span></code> with the argument tuple <em>args</em> and the keyword arguments in
|
||
the dictionary <em>kw</em>. <code class="xref py py-func docutils literal notranslate"><span class="pre">apply()</span></code> is the same in 2.0, but thanks to a patch
|
||
from Greg Ewing, <code class="docutils literal notranslate"><span class="pre">f(*args,</span> <span class="pre">**kw)</span></code> is a shorter and clearer way to achieve the
|
||
same effect. This syntax is symmetrical with the syntax for defining
|
||
functions:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">f</span><span class="p">(</span><span class="o">*</span><span class="n">args</span><span class="p">,</span> <span class="o">**</span><span class="n">kw</span><span class="p">):</span>
|
||
<span class="c1"># args is a tuple of positional args,</span>
|
||
<span class="c1"># kw is a dictionary of keyword args</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">print</span></code> statement can now have its output directed to a file-like
|
||
object by following the <code class="docutils literal notranslate"><span class="pre">print</span></code> with <code class="docutils literal notranslate"><span class="pre">>></span> <span class="pre">file</span></code>, similar to the
|
||
redirection operator in Unix shells. Previously you’d either have to use the
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">write()</span></code> method of the file-like object, which lacks the convenience and
|
||
simplicity of <code class="docutils literal notranslate"><span class="pre">print</span></code>, or you could assign a new value to
|
||
<code class="docutils literal notranslate"><span class="pre">sys.stdout</span></code> and then restore the old value. For sending output to standard
|
||
error, it’s much easier to write this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="nb">print</span> <span class="o">>></span> <span class="n">sys</span><span class="o">.</span><span class="n">stderr</span><span class="p">,</span> <span class="s2">"Warning: action field not supplied"</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Modules can now be renamed on importing them, using the syntax <code class="docutils literal notranslate"><span class="pre">import</span> <span class="pre">module</span>
|
||
<span class="pre">as</span> <span class="pre">name</span></code> or <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">name</span> <span class="pre">as</span> <span class="pre">othername</span></code>. The patch was submitted
|
||
by Thomas Wouters.</p>
|
||
<p>A new format style is available when using the <code class="docutils literal notranslate"><span class="pre">%</span></code> operator; ‘%r’ will insert
|
||
the <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> of its argument. This was also added from symmetry
|
||
considerations, this time for symmetry with the existing ‘%s’ format style,
|
||
which inserts the <a class="reference internal" href="../library/stdtypes.html#str" title="str"><code class="xref py py-func docutils literal notranslate"><span class="pre">str()</span></code></a> of its argument. For example, <code class="docutils literal notranslate"><span class="pre">'%r</span> <span class="pre">%s'</span> <span class="pre">%</span> <span class="pre">('abc',</span>
|
||
<span class="pre">'abc')</span></code> returns a string containing <code class="docutils literal notranslate"><span class="pre">'abc'</span> <span class="pre">abc</span></code>.</p>
|
||
<p>Previously there was no way to implement a class that overrode Python’s built-in
|
||
<a class="reference internal" href="../reference/expressions.html#in"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">in</span></code></a> operator and implemented a custom version. <code class="docutils literal notranslate"><span class="pre">obj</span> <span class="pre">in</span> <span class="pre">seq</span></code> returns
|
||
true if <em>obj</em> is present in the sequence <em>seq</em>; Python computes this by simply
|
||
trying every index of the sequence until either <em>obj</em> is found or an
|
||
<a class="reference internal" href="../library/exceptions.html#IndexError" title="IndexError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">IndexError</span></code></a> is encountered. Moshe Zadka contributed a patch which adds a
|
||
<a class="reference internal" href="../reference/datamodel.html#object.__contains__" title="object.__contains__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__contains__()</span></code></a> magic method for providing a custom implementation for
|
||
<code class="xref std std-keyword docutils literal notranslate"><span class="pre">in</span></code>. Additionally, new built-in objects written in C can define what
|
||
<code class="xref std std-keyword docutils literal notranslate"><span class="pre">in</span></code> means for them via a new slot in the sequence protocol.</p>
|
||
<p>Earlier versions of Python used a recursive algorithm for deleting objects.
|
||
Deeply nested data structures could cause the interpreter to fill up the C stack
|
||
and crash; Christian Tismer rewrote the deletion logic to fix this problem. On
|
||
a related note, comparing recursive objects recursed infinitely and crashed;
|
||
Jeremy Hylton rewrote the code to no longer crash, producing a useful result
|
||
instead. For example, after this code:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">a</span> <span class="o">=</span> <span class="p">[]</span>
|
||
<span class="n">b</span> <span class="o">=</span> <span class="p">[]</span>
|
||
<span class="n">a</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">a</span><span class="p">)</span>
|
||
<span class="n">b</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">b</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The comparison <code class="docutils literal notranslate"><span class="pre">a==b</span></code> returns true, because the two recursive data structures
|
||
are isomorphic. See the thread “trashcan and PR#7” in the April 2000 archives of
|
||
the python-dev mailing list for the discussion leading up to this
|
||
implementation, and some useful relevant links. Note that comparisons can now
|
||
also raise exceptions. In earlier versions of Python, a comparison operation
|
||
such as <code class="docutils literal notranslate"><span class="pre">cmp(a,b)</span></code> would always produce an answer, even if a user-defined
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">__cmp__()</span></code> method encountered an error, since the resulting exception would
|
||
simply be silently swallowed.</p>
|
||
<p>Work has been done on porting Python to 64-bit Windows on the Itanium processor,
|
||
mostly by Trent Mick of ActiveState. (Confusingly, <code class="docutils literal notranslate"><span class="pre">sys.platform</span></code> is still
|
||
<code class="docutils literal notranslate"><span class="pre">'win32'</span></code> on Win64 because it seems that for ease of porting, MS Visual C++
|
||
treats code as 32 bit on Itanium.) PythonWin also supports Windows CE; see the
|
||
Python CE page at <a class="reference external" href="http://pythonce.sourceforge.net/">http://pythonce.sourceforge.net/</a> for more information.</p>
|
||
<p>Another new platform is Darwin/MacOS X; initial support for it is in Python 2.0.
|
||
Dynamic loading works, if you specify “configure –with-dyld –with-suffix=.x”.
|
||
Consult the README in the Python source distribution for more instructions.</p>
|
||
<p>An attempt has been made to alleviate one of Python’s warts, the often-confusing
|
||
<a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a> exception when code refers to a local variable before the
|
||
variable has been assigned a value. For example, the following code raises an
|
||
exception on the <code class="docutils literal notranslate"><span class="pre">print</span></code> statement in both 1.5.2 and 2.0; in 1.5.2 a
|
||
<a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a> exception is raised, while 2.0 raises a new
|
||
<a class="reference internal" href="../library/exceptions.html#UnboundLocalError" title="UnboundLocalError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">UnboundLocalError</span></code></a> exception. <a class="reference internal" href="../library/exceptions.html#UnboundLocalError" title="UnboundLocalError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">UnboundLocalError</span></code></a> is a subclass of
|
||
<a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a>, so any existing code that expects <a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a> to be
|
||
raised should still work.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">f</span><span class="p">():</span>
|
||
<span class="nb">print</span> <span class="s2">"i="</span><span class="p">,</span><span class="n">i</span>
|
||
<span class="n">i</span> <span class="o">=</span> <span class="n">i</span> <span class="o">+</span> <span class="mi">1</span>
|
||
<span class="n">f</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Two new exceptions, <a class="reference internal" href="../library/exceptions.html#TabError" title="TabError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TabError</span></code></a> and <a class="reference internal" href="../library/exceptions.html#IndentationError" title="IndentationError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">IndentationError</span></code></a>, have been
|
||
introduced. They’re both subclasses of <a class="reference internal" href="../library/exceptions.html#SyntaxError" title="SyntaxError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">SyntaxError</span></code></a>, and are raised when
|
||
Python code is found to be improperly indented.</p>
|
||
</div>
|
||
<div class="section" id="changes-to-built-in-functions">
|
||
<h3>Changes to Built-in Functions<a class="headerlink" href="#changes-to-built-in-functions" title="Permalink to this headline">¶</a></h3>
|
||
<p>A new built-in, <code class="docutils literal notranslate"><span class="pre">zip(seq1,</span> <span class="pre">seq2,</span> <span class="pre">...)</span></code>, has been added. <a class="reference internal" href="../library/functions.html#zip" title="zip"><code class="xref py py-func docutils literal notranslate"><span class="pre">zip()</span></code></a>
|
||
returns a list of tuples where each tuple contains the i-th element from each of
|
||
the argument sequences. The difference between <a class="reference internal" href="../library/functions.html#zip" title="zip"><code class="xref py py-func docutils literal notranslate"><span class="pre">zip()</span></code></a> and <code class="docutils literal notranslate"><span class="pre">map(None,</span>
|
||
<span class="pre">seq1,</span> <span class="pre">seq2)</span></code> is that <a class="reference internal" href="../library/functions.html#map" title="map"><code class="xref py py-func docutils literal notranslate"><span class="pre">map()</span></code></a> pads the sequences with <code class="docutils literal notranslate"><span class="pre">None</span></code> if the
|
||
sequences aren’t all of the same length, while <a class="reference internal" href="../library/functions.html#zip" title="zip"><code class="xref py py-func docutils literal notranslate"><span class="pre">zip()</span></code></a> truncates the
|
||
returned list to the length of the shortest argument sequence.</p>
|
||
<p>The <a class="reference internal" href="../library/functions.html#int" title="int"><code class="xref py py-func docutils literal notranslate"><span class="pre">int()</span></code></a> and <code class="xref py py-func docutils literal notranslate"><span class="pre">long()</span></code> functions now accept an optional “base”
|
||
parameter when the first argument is a string. <code class="docutils literal notranslate"><span class="pre">int('123',</span> <span class="pre">10)</span></code> returns 123,
|
||
while <code class="docutils literal notranslate"><span class="pre">int('123',</span> <span class="pre">16)</span></code> returns 291. <code class="docutils literal notranslate"><span class="pre">int(123,</span> <span class="pre">16)</span></code> raises a
|
||
<a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TypeError</span></code></a> exception with the message “can’t convert non-string with
|
||
explicit base”.</p>
|
||
<p>A new variable holding more detailed version information has been added to the
|
||
<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> module. <code class="docutils literal notranslate"><span class="pre">sys.version_info</span></code> is a tuple <code class="docutils literal notranslate"><span class="pre">(major,</span> <span class="pre">minor,</span> <span class="pre">micro,</span>
|
||
<span class="pre">level,</span> <span class="pre">serial)</span></code> For example, in a hypothetical 2.0.1beta1, <code class="docutils literal notranslate"><span class="pre">sys.version_info</span></code>
|
||
would be <code class="docutils literal notranslate"><span class="pre">(2,</span> <span class="pre">0,</span> <span class="pre">1,</span> <span class="pre">'beta',</span> <span class="pre">1)</span></code>. <em>level</em> is a string such as <code class="docutils literal notranslate"><span class="pre">"alpha"</span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre">"beta"</span></code>, or <code class="docutils literal notranslate"><span class="pre">"final"</span></code> for a final release.</p>
|
||
<p>Dictionaries have an odd new method, <code class="docutils literal notranslate"><span class="pre">setdefault(key,</span> <span class="pre">default)</span></code>, which
|
||
behaves similarly to the existing <code class="xref py py-meth docutils literal notranslate"><span class="pre">get()</span></code> method. However, if the key is
|
||
missing, <code class="xref py py-meth docutils literal notranslate"><span class="pre">setdefault()</span></code> both returns the value of <em>default</em> as <code class="xref py py-meth docutils literal notranslate"><span class="pre">get()</span></code>
|
||
would do, and also inserts it into the dictionary as the value for <em>key</em>. Thus,
|
||
the following lines of code:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">if</span> <span class="nb">dict</span><span class="o">.</span><span class="n">has_key</span><span class="p">(</span> <span class="n">key</span> <span class="p">):</span> <span class="k">return</span> <span class="nb">dict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
<span class="k">else</span><span class="p">:</span>
|
||
<span class="nb">dict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span> <span class="o">=</span> <span class="p">[]</span>
|
||
<span class="k">return</span> <span class="nb">dict</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>can be reduced to a single <code class="docutils literal notranslate"><span class="pre">return</span> <span class="pre">dict.setdefault(key,</span> <span class="pre">[])</span></code> statement.</p>
|
||
<p>The interpreter sets a maximum recursion depth in order to catch runaway
|
||
recursion before filling the C stack and causing a core dump or GPF..
|
||
Previously this limit was fixed when you compiled Python, but in 2.0 the maximum
|
||
recursion depth can be read and modified using <a class="reference internal" href="../library/sys.html#sys.getrecursionlimit" title="sys.getrecursionlimit"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.getrecursionlimit()</span></code></a> and
|
||
<a class="reference internal" href="../library/sys.html#sys.setrecursionlimit" title="sys.setrecursionlimit"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.setrecursionlimit()</span></code></a>. The default value is 1000, and a rough maximum
|
||
value for a given platform can be found by running a new script,
|
||
<code class="file docutils literal notranslate"><span class="pre">Misc/find_recursionlimit.py</span></code>.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="porting-to-2-0">
|
||
<h2>Porting to 2.0<a class="headerlink" href="#porting-to-2-0" title="Permalink to this headline">¶</a></h2>
|
||
<p>New Python releases try hard to be compatible with previous releases, and the
|
||
record has been pretty good. However, some changes are considered useful
|
||
enough, usually because they fix initial design decisions that turned out to be
|
||
actively mistaken, that breaking backward compatibility can’t always be avoided.
|
||
This section lists the changes in Python 2.0 that may cause old Python code to
|
||
break.</p>
|
||
<p>The change which will probably break the most code is tightening up the
|
||
arguments accepted by some methods. Some methods would take multiple arguments
|
||
and treat them as a tuple, particularly various list methods such as
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">append()</span></code> and <code class="xref py py-meth docutils literal notranslate"><span class="pre">insert()</span></code>. In earlier versions of Python, if <code class="docutils literal notranslate"><span class="pre">L</span></code> is
|
||
a list, <code class="docutils literal notranslate"><span class="pre">L.append(</span> <span class="pre">1,2</span> <span class="pre">)</span></code> appends the tuple <code class="docutils literal notranslate"><span class="pre">(1,2)</span></code> to the list. In Python
|
||
2.0 this causes a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TypeError</span></code></a> exception to be raised, with the message:
|
||
‘append requires exactly 1 argument; 2 given’. The fix is to simply add an
|
||
extra set of parentheses to pass both values as a tuple: <code class="docutils literal notranslate"><span class="pre">L.append(</span> <span class="pre">(1,2)</span> <span class="pre">)</span></code>.</p>
|
||
<p>The earlier versions of these methods were more forgiving because they used an
|
||
old function in Python’s C interface to parse their arguments; 2.0 modernizes
|
||
them to use <code class="xref py py-func docutils literal notranslate"><span class="pre">PyArg_ParseTuple()</span></code>, the current argument parsing function,
|
||
which provides more helpful error messages and treats multi-argument calls as
|
||
errors. If you absolutely must use 2.0 but can’t fix your code, you can edit
|
||
<code class="file docutils literal notranslate"><span class="pre">Objects/listobject.c</span></code> and define the preprocessor symbol
|
||
<code class="docutils literal notranslate"><span class="pre">NO_STRICT_LIST_APPEND</span></code> to preserve the old behaviour; this isn’t recommended.</p>
|
||
<p>Some of the functions in the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">socket</span></code></a> module are still forgiving in this
|
||
way. For example, <code class="xref py py-func docutils literal notranslate"><span class="pre">socket.connect(</span> <span class="pre">('hostname',</span> <span class="pre">25)</span> <span class="pre">)()</span></code> is the correct
|
||
form, passing a tuple representing an IP address, but <code class="xref py py-func docutils literal notranslate"><span class="pre">socket.connect(</span>
|
||
<span class="pre">'hostname',</span> <span class="pre">25</span> <span class="pre">)()</span></code> also works. <code class="xref py py-func docutils literal notranslate"><span class="pre">socket.connect_ex()</span></code> and <code class="xref py py-func docutils literal notranslate"><span class="pre">socket.bind()</span></code>
|
||
are similarly easy-going. 2.0alpha1 tightened these functions up, but because
|
||
the documentation actually used the erroneous multiple argument form, many
|
||
people wrote code which would break with the stricter checking. GvR backed out
|
||
the changes in the face of public reaction, so for the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">socket</span></code></a> module, the
|
||
documentation was fixed and the multiple argument form is simply marked as
|
||
deprecated; it <em>will</em> be tightened up again in a future Python version.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">\x</span></code> escape in string literals now takes exactly 2 hex digits. Previously
|
||
it would consume all the hex digits following the ‘x’ and take the lowest 8 bits
|
||
of the result, so <code class="docutils literal notranslate"><span class="pre">\x123456</span></code> was equivalent to <code class="docutils literal notranslate"><span class="pre">\x56</span></code>.</p>
|
||
<p>The <a class="reference internal" href="../library/exceptions.html#AttributeError" title="AttributeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">AttributeError</span></code></a> and <a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">NameError</span></code></a> exceptions have a more friendly
|
||
error message, whose text will be something like <code class="docutils literal notranslate"><span class="pre">'Spam'</span> <span class="pre">instance</span> <span class="pre">has</span> <span class="pre">no</span>
|
||
<span class="pre">attribute</span> <span class="pre">'eggs'</span></code> or <code class="docutils literal notranslate"><span class="pre">name</span> <span class="pre">'eggs'</span> <span class="pre">is</span> <span class="pre">not</span> <span class="pre">defined</span></code>. Previously the error
|
||
message was just the missing attribute name <code class="docutils literal notranslate"><span class="pre">eggs</span></code>, and code written to take
|
||
advantage of this fact will break in 2.0.</p>
|
||
<p>Some work has been done to make integers and long integers a bit more
|
||
interchangeable. In 1.5.2, large-file support was added for Solaris, to allow
|
||
reading files larger than 2 GiB; this made the <code class="xref py py-meth docutils literal notranslate"><span class="pre">tell()</span></code> method of file
|
||
objects return a long integer instead of a regular integer. Some code would
|
||
subtract two file offsets and attempt to use the result to multiply a sequence
|
||
or slice a string, but this raised a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">TypeError</span></code></a>. In 2.0, long integers
|
||
can be used to multiply or slice a sequence, and it’ll behave as you’d
|
||
intuitively expect it to; <code class="docutils literal notranslate"><span class="pre">3L</span> <span class="pre">*</span> <span class="pre">'abc'</span></code> produces ‘abcabcabc’, and
|
||
<code class="docutils literal notranslate"><span class="pre">(0,1,2,3)[2L:4L]</span></code> produces (2,3). Long integers can also be used in various
|
||
contexts where previously only integers were accepted, such as in the
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">seek()</span></code> method of file objects, and in the formats supported by the <code class="docutils literal notranslate"><span class="pre">%</span></code>
|
||
operator (<code class="docutils literal notranslate"><span class="pre">%d</span></code>, <code class="docutils literal notranslate"><span class="pre">%i</span></code>, <code class="docutils literal notranslate"><span class="pre">%x</span></code>, etc.). For example, <code class="docutils literal notranslate"><span class="pre">"%d"</span> <span class="pre">%</span> <span class="pre">2L**64</span></code> will
|
||
produce the string <code class="docutils literal notranslate"><span class="pre">18446744073709551616</span></code>.</p>
|
||
<p>The subtlest long integer change of all is that the <a class="reference internal" href="../library/stdtypes.html#str" title="str"><code class="xref py py-func docutils literal notranslate"><span class="pre">str()</span></code></a> of a long
|
||
integer no longer has a trailing ‘L’ character, though <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> still
|
||
includes it. The ‘L’ annoyed many people who wanted to print long integers that
|
||
looked just like regular integers, since they had to go out of their way to chop
|
||
off the character. This is no longer a problem in 2.0, but code which does
|
||
<code class="docutils literal notranslate"><span class="pre">str(longval)[:-1]</span></code> and assumes the ‘L’ is there, will now lose the final
|
||
digit.</p>
|
||
<p>Taking the <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> of a float now uses a different formatting precision
|
||
than <a class="reference internal" href="../library/stdtypes.html#str" title="str"><code class="xref py py-func docutils literal notranslate"><span class="pre">str()</span></code></a>. <a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> uses <code class="docutils literal notranslate"><span class="pre">%.17g</span></code> format string for C’s
|
||
<code class="xref py py-func docutils literal notranslate"><span class="pre">sprintf()</span></code>, while <a class="reference internal" href="../library/stdtypes.html#str" title="str"><code class="xref py py-func docutils literal notranslate"><span class="pre">str()</span></code></a> uses <code class="docutils literal notranslate"><span class="pre">%.12g</span></code> as before. The effect is that
|
||
<a class="reference internal" href="../library/functions.html#repr" title="repr"><code class="xref py py-func docutils literal notranslate"><span class="pre">repr()</span></code></a> may occasionally show more decimal places than <a class="reference internal" href="../library/stdtypes.html#str" title="str"><code class="xref py py-func docutils literal notranslate"><span class="pre">str()</span></code></a>, for
|
||
certain numbers. For example, the number 8.1 can’t be represented exactly in
|
||
binary, so <code class="docutils literal notranslate"><span class="pre">repr(8.1)</span></code> is <code class="docutils literal notranslate"><span class="pre">'8.0999999999999996'</span></code>, while str(8.1) is
|
||
<code class="docutils literal notranslate"><span class="pre">'8.1'</span></code>.</p>
|
||
<p>The <code class="docutils literal notranslate"><span class="pre">-X</span></code> command-line option, which turned all standard exceptions into
|
||
strings instead of classes, has been removed; the standard exceptions will now
|
||
always be classes. The <code class="xref py py-mod docutils literal notranslate"><span class="pre">exceptions</span></code> module containing the standard
|
||
exceptions was translated from Python to a built-in C module, written by Barry
|
||
Warsaw and Fredrik Lundh.</p>
|
||
</div>
|
||
<div class="section" id="extending-embedding-changes">
|
||
<h2>Extending/Embedding Changes<a class="headerlink" href="#extending-embedding-changes" title="Permalink to this headline">¶</a></h2>
|
||
<p>Some of the changes are under the covers, and will only be apparent to people
|
||
writing C extension modules or embedding a Python interpreter in a larger
|
||
application. If you aren’t dealing with Python’s C API, you can safely skip
|
||
this section.</p>
|
||
<p>The version number of the Python C API was incremented, so C extensions compiled
|
||
for 1.5.2 must be recompiled in order to work with 2.0. On Windows, it’s not
|
||
possible for Python 2.0 to import a third party extension built for Python 1.5.x
|
||
due to how Windows DLLs work, so Python will raise an exception and the import
|
||
will fail.</p>
|
||
<p>Users of Jim Fulton’s ExtensionClass module will be pleased to find out that
|
||
hooks have been added so that ExtensionClasses are now supported by
|
||
<a class="reference internal" href="../library/functions.html#isinstance" title="isinstance"><code class="xref py py-func docutils literal notranslate"><span class="pre">isinstance()</span></code></a> and <a class="reference internal" href="../library/functions.html#issubclass" title="issubclass"><code class="xref py py-func docutils literal notranslate"><span class="pre">issubclass()</span></code></a>. This means you no longer have to
|
||
remember to write code such as <code class="docutils literal notranslate"><span class="pre">if</span> <span class="pre">type(obj)</span> <span class="pre">==</span> <span class="pre">myExtensionClass</span></code>, but can use
|
||
the more natural <code class="docutils literal notranslate"><span class="pre">if</span> <span class="pre">isinstance(obj,</span> <span class="pre">myExtensionClass)</span></code>.</p>
|
||
<p>The <code class="file docutils literal notranslate"><span class="pre">Python/importdl.c</span></code> file, which was a mass of #ifdefs to support
|
||
dynamic loading on many different platforms, was cleaned up and reorganised by
|
||
Greg Stein. <code class="file docutils literal notranslate"><span class="pre">importdl.c</span></code> is now quite small, and platform-specific code
|
||
has been moved into a bunch of <code class="file docutils literal notranslate"><span class="pre">Python/dynload_*.c</span></code> files. Another
|
||
cleanup: there were also a number of <code class="file docutils literal notranslate"><span class="pre">my*.h</span></code> files in the Include/
|
||
directory that held various portability hacks; they’ve been merged into a single
|
||
file, <code class="file docutils literal notranslate"><span class="pre">Include/pyport.h</span></code>.</p>
|
||
<p>Vladimir Marangozov’s long-awaited malloc restructuring was completed, to make
|
||
it easy to have the Python interpreter use a custom allocator instead of C’s
|
||
standard <code class="xref py py-func docutils literal notranslate"><span class="pre">malloc()</span></code>. For documentation, read the comments in
|
||
<code class="file docutils literal notranslate"><span class="pre">Include/pymem.h</span></code> and <code class="file docutils literal notranslate"><span class="pre">Include/objimpl.h</span></code>. For the lengthy
|
||
discussions during which the interface was hammered out, see the Web archives of
|
||
the ‘patches’ and ‘python-dev’ lists at python.org.</p>
|
||
<p>Recent versions of the GUSI development environment for MacOS support POSIX
|
||
threads. Therefore, Python’s POSIX threading support now works on the
|
||
Macintosh. Threading support using the user-space GNU <code class="docutils literal notranslate"><span class="pre">pth</span></code> library was also
|
||
contributed.</p>
|
||
<p>Threading support on Windows was enhanced, too. Windows supports thread locks
|
||
that use kernel objects only in case of contention; in the common case when
|
||
there’s no contention, they use simpler functions which are an order of
|
||
magnitude faster. A threaded version of Python 1.5.2 on NT is twice as slow as
|
||
an unthreaded version; with the 2.0 changes, the difference is only 10%. These
|
||
improvements were contributed by Yakov Markovitch.</p>
|
||
<p>Python 2.0’s source now uses only ANSI C prototypes, so compiling Python now
|
||
requires an ANSI C compiler, and can no longer be done using a compiler that
|
||
only supports K&R C.</p>
|
||
<p>Previously the Python virtual machine used 16-bit numbers in its bytecode,
|
||
limiting the size of source files. In particular, this affected the maximum
|
||
size of literal lists and dictionaries in Python source; occasionally people who
|
||
are generating Python code would run into this limit. A patch by Charles G.
|
||
Waldman raises the limit from <code class="docutils literal notranslate"><span class="pre">2^16</span></code> to <code class="docutils literal notranslate"><span class="pre">2^{32}</span></code>.</p>
|
||
<p>Three new convenience functions intended for adding constants to a module’s
|
||
dictionary at module initialization time were added: <code class="xref py py-func docutils literal notranslate"><span class="pre">PyModule_AddObject()</span></code>,
|
||
<code class="xref py py-func docutils literal notranslate"><span class="pre">PyModule_AddIntConstant()</span></code>, and <code class="xref py py-func docutils literal notranslate"><span class="pre">PyModule_AddStringConstant()</span></code>. Each
|
||
of these functions takes a module object, a null-terminated C string containing
|
||
the name to be added, and a third argument for the value to be assigned to the
|
||
name. This third argument is, respectively, a Python object, a C long, or a C
|
||
string.</p>
|
||
<p>A wrapper API was added for Unix-style signal handlers. <code class="xref py py-func docutils literal notranslate"><span class="pre">PyOS_getsig()</span></code> gets
|
||
a signal handler and <code class="xref py py-func docutils literal notranslate"><span class="pre">PyOS_setsig()</span></code> will set a new handler.</p>
|
||
</div>
|
||
<div class="section" id="distutils-making-modules-easy-to-install">
|
||
<h2>Distutils: Making Modules Easy to Install<a class="headerlink" href="#distutils-making-modules-easy-to-install" title="Permalink to this headline">¶</a></h2>
|
||
<p>Before Python 2.0, installing modules was a tedious affair – there was no way
|
||
to figure out automatically where Python is installed, or what compiler options
|
||
to use for extension modules. Software authors had to go through an arduous
|
||
ritual of editing Makefiles and configuration files, which only really work on
|
||
Unix and leave Windows and MacOS unsupported. Python users faced wildly
|
||
differing installation instructions which varied between different extension
|
||
packages, which made administering a Python installation something of a chore.</p>
|
||
<p>The SIG for distribution utilities, shepherded by Greg Ward, has created the
|
||
Distutils, a system to make package installation much easier. They form the
|
||
<a class="reference internal" href="../library/distutils.html#module-distutils" title="distutils: Support for building and installing Python modules into an existing Python installation."><code class="xref py py-mod docutils literal notranslate"><span class="pre">distutils</span></code></a> package, a new part of Python’s standard library. In the best
|
||
case, installing a Python module from source will require the same steps: first
|
||
you simply mean unpack the tarball or zip archive, and the run “<code class="docutils literal notranslate"><span class="pre">python</span>
|
||
<span class="pre">setup.py</span> <span class="pre">install</span></code>”. The platform will be automatically detected, the compiler
|
||
will be recognized, C extension modules will be compiled, and the distribution
|
||
installed into the proper directory. Optional command-line arguments provide
|
||
more control over the installation process, the distutils package offers many
|
||
places to override defaults – separating the build from the install, building
|
||
or installing in non-default directories, and more.</p>
|
||
<p>In order to use the Distutils, you need to write a <code class="file docutils literal notranslate"><span class="pre">setup.py</span></code> script. For
|
||
the simple case, when the software contains only .py files, a minimal
|
||
<code class="file docutils literal notranslate"><span class="pre">setup.py</span></code> can be just a few lines long:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">distutils.core</span> <span class="k">import</span> <span class="n">setup</span>
|
||
<span class="n">setup</span> <span class="p">(</span><span class="n">name</span> <span class="o">=</span> <span class="s2">"foo"</span><span class="p">,</span> <span class="n">version</span> <span class="o">=</span> <span class="s2">"1.0"</span><span class="p">,</span>
|
||
<span class="n">py_modules</span> <span class="o">=</span> <span class="p">[</span><span class="s2">"module1"</span><span class="p">,</span> <span class="s2">"module2"</span><span class="p">])</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="file docutils literal notranslate"><span class="pre">setup.py</span></code> file isn’t much more complicated if the software consists
|
||
of a few packages:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">distutils.core</span> <span class="k">import</span> <span class="n">setup</span>
|
||
<span class="n">setup</span> <span class="p">(</span><span class="n">name</span> <span class="o">=</span> <span class="s2">"foo"</span><span class="p">,</span> <span class="n">version</span> <span class="o">=</span> <span class="s2">"1.0"</span><span class="p">,</span>
|
||
<span class="n">packages</span> <span class="o">=</span> <span class="p">[</span><span class="s2">"package"</span><span class="p">,</span> <span class="s2">"package.subpackage"</span><span class="p">])</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>A C extension can be the most complicated case; here’s an example taken from
|
||
the PyXML package:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">distutils.core</span> <span class="k">import</span> <span class="n">setup</span><span class="p">,</span> <span class="n">Extension</span>
|
||
|
||
<span class="n">expat_extension</span> <span class="o">=</span> <span class="n">Extension</span><span class="p">(</span><span class="s1">'xml.parsers.pyexpat'</span><span class="p">,</span>
|
||
<span class="n">define_macros</span> <span class="o">=</span> <span class="p">[(</span><span class="s1">'XML_NS'</span><span class="p">,</span> <span class="kc">None</span><span class="p">)],</span>
|
||
<span class="n">include_dirs</span> <span class="o">=</span> <span class="p">[</span> <span class="s1">'extensions/expat/xmltok'</span><span class="p">,</span>
|
||
<span class="s1">'extensions/expat/xmlparse'</span> <span class="p">],</span>
|
||
<span class="n">sources</span> <span class="o">=</span> <span class="p">[</span> <span class="s1">'extensions/pyexpat.c'</span><span class="p">,</span>
|
||
<span class="s1">'extensions/expat/xmltok/xmltok.c'</span><span class="p">,</span>
|
||
<span class="s1">'extensions/expat/xmltok/xmlrole.c'</span><span class="p">,</span> <span class="p">]</span>
|
||
<span class="p">)</span>
|
||
<span class="n">setup</span> <span class="p">(</span><span class="n">name</span> <span class="o">=</span> <span class="s2">"PyXML"</span><span class="p">,</span> <span class="n">version</span> <span class="o">=</span> <span class="s2">"0.5.4"</span><span class="p">,</span>
|
||
<span class="n">ext_modules</span> <span class="o">=</span><span class="p">[</span> <span class="n">expat_extension</span> <span class="p">]</span> <span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The Distutils can also take care of creating source and binary distributions.
|
||
The “sdist” command, run by “<code class="docutils literal notranslate"><span class="pre">python</span> <span class="pre">setup.py</span> <span class="pre">sdist</span></code>’, builds a source
|
||
distribution such as <code class="file docutils literal notranslate"><span class="pre">foo-1.0.tar.gz</span></code>. Adding new commands isn’t
|
||
difficult, “bdist_rpm” and “bdist_wininst” commands have already been
|
||
contributed to create an RPM distribution and a Windows installer for the
|
||
software, respectively. Commands to create other distribution formats such as
|
||
Debian packages and Solaris <code class="file docutils literal notranslate"><span class="pre">.pkg</span></code> files are in various stages of
|
||
development.</p>
|
||
<p>All this is documented in a new manual, <em>Distributing Python Modules</em>, that
|
||
joins the basic set of Python documentation.</p>
|
||
</div>
|
||
<div class="section" id="xml-modules">
|
||
<h2>XML Modules<a class="headerlink" href="#xml-modules" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python 1.5.2 included a simple XML parser in the form of the <code class="xref py py-mod docutils literal notranslate"><span class="pre">xmllib</span></code>
|
||
module, contributed by Sjoerd Mullender. Since 1.5.2’s release, two different
|
||
interfaces for processing XML have become common: SAX2 (version 2 of the Simple
|
||
API for XML) provides an event-driven interface with some similarities to
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">xmllib</span></code>, and the DOM (Document Object Model) provides a tree-based
|
||
interface, transforming an XML document into a tree of nodes that can be
|
||
traversed and modified. Python 2.0 includes a SAX2 interface and a stripped-down
|
||
DOM interface as part of the <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml</span></code></a> package. Here we will give a brief
|
||
overview of these new interfaces; consult the Python documentation or the source
|
||
code for complete details. The Python XML SIG is also working on improved
|
||
documentation.</p>
|
||
<div class="section" id="sax2-support">
|
||
<h3>SAX2 Support<a class="headerlink" href="#sax2-support" title="Permalink to this headline">¶</a></h3>
|
||
<p>SAX defines an event-driven interface for parsing XML. To use SAX, you must
|
||
write a SAX handler class. Handler classes inherit from various classes
|
||
provided by SAX, and override various methods that will then be called by the
|
||
XML parser. For example, the <code class="xref py py-meth docutils literal notranslate"><span class="pre">startElement()</span></code> and <code class="xref py py-meth docutils literal notranslate"><span class="pre">endElement()</span></code>
|
||
methods are called for every starting and end tag encountered by the parser, the
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">characters()</span></code> method is called for every chunk of character data, and so
|
||
forth.</p>
|
||
<p>The advantage of the event-driven approach is that the whole document doesn’t
|
||
have to be resident in memory at any one time, which matters if you are
|
||
processing really huge documents. However, writing the SAX handler class can
|
||
get very complicated if you’re trying to modify the document structure in some
|
||
elaborate way.</p>
|
||
<p>For example, this little example program defines a handler that prints a message
|
||
for every starting and ending tag, and then parses the file <code class="file docutils literal notranslate"><span class="pre">hamlet.xml</span></code>
|
||
using it:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">xml</span> <span class="k">import</span> <span class="n">sax</span>
|
||
|
||
<span class="k">class</span> <span class="nc">SimpleHandler</span><span class="p">(</span><span class="n">sax</span><span class="o">.</span><span class="n">ContentHandler</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">startElement</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">attrs</span><span class="p">):</span>
|
||
<span class="nb">print</span> <span class="s1">'Start of element:'</span><span class="p">,</span> <span class="n">name</span><span class="p">,</span> <span class="n">attrs</span><span class="o">.</span><span class="n">keys</span><span class="p">()</span>
|
||
|
||
<span class="k">def</span> <span class="nf">endElement</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">name</span><span class="p">):</span>
|
||
<span class="nb">print</span> <span class="s1">'End of element:'</span><span class="p">,</span> <span class="n">name</span>
|
||
|
||
<span class="c1"># Create a parser object</span>
|
||
<span class="n">parser</span> <span class="o">=</span> <span class="n">sax</span><span class="o">.</span><span class="n">make_parser</span><span class="p">()</span>
|
||
|
||
<span class="c1"># Tell it what handler to use</span>
|
||
<span class="n">handler</span> <span class="o">=</span> <span class="n">SimpleHandler</span><span class="p">()</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">setContentHandler</span><span class="p">(</span> <span class="n">handler</span> <span class="p">)</span>
|
||
|
||
<span class="c1"># Parse a file!</span>
|
||
<span class="n">parser</span><span class="o">.</span><span class="n">parse</span><span class="p">(</span> <span class="s1">'hamlet.xml'</span> <span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For more information, consult the Python documentation, or the XML HOWTO at
|
||
<a class="reference external" href="http://pyxml.sourceforge.net/topics/howto/xml-howto.html">http://pyxml.sourceforge.net/topics/howto/xml-howto.html</a>.</p>
|
||
</div>
|
||
<div class="section" id="dom-support">
|
||
<h3>DOM Support<a class="headerlink" href="#dom-support" title="Permalink to this headline">¶</a></h3>
|
||
<p>The Document Object Model is a tree-based representation for an XML document. A
|
||
top-level <code class="xref py py-class docutils literal notranslate"><span class="pre">Document</span></code> instance is the root of the tree, and has a single
|
||
child which is the top-level <code class="xref py py-class docutils literal notranslate"><span class="pre">Element</span></code> instance. This <code class="xref py py-class docutils literal notranslate"><span class="pre">Element</span></code>
|
||
has children nodes representing character data and any sub-elements, which may
|
||
have further children of their own, and so forth. Using the DOM you can
|
||
traverse the resulting tree any way you like, access element and attribute
|
||
values, insert and delete nodes, and convert the tree back into XML.</p>
|
||
<p>The DOM is useful for modifying XML documents, because you can create a DOM
|
||
tree, modify it by adding new nodes or rearranging subtrees, and then produce a
|
||
new XML document as output. You can also construct a DOM tree manually and
|
||
convert it to XML, which can be a more flexible way of producing XML output than
|
||
simply writing <code class="docutils literal notranslate"><span class="pre"><tag1></span></code>…<code class="docutils literal notranslate"><span class="pre"></tag1></span></code> to a file.</p>
|
||
<p>The DOM implementation included with Python lives in the <a class="reference internal" href="../library/xml.dom.minidom.html#module-xml.dom.minidom" title="xml.dom.minidom: Minimal Document Object Model (DOM) implementation."><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml.dom.minidom</span></code></a>
|
||
module. It’s a lightweight implementation of the Level 1 DOM with support for
|
||
XML namespaces. The <code class="xref py py-func docutils literal notranslate"><span class="pre">parse()</span></code> and <code class="xref py py-func docutils literal notranslate"><span class="pre">parseString()</span></code> convenience
|
||
functions are provided for generating a DOM tree:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">xml.dom</span> <span class="k">import</span> <span class="n">minidom</span>
|
||
<span class="n">doc</span> <span class="o">=</span> <span class="n">minidom</span><span class="o">.</span><span class="n">parse</span><span class="p">(</span><span class="s1">'hamlet.xml'</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p><code class="docutils literal notranslate"><span class="pre">doc</span></code> is a <code class="xref py py-class docutils literal notranslate"><span class="pre">Document</span></code> instance. <code class="xref py py-class docutils literal notranslate"><span class="pre">Document</span></code>, like all the other
|
||
DOM classes such as <code class="xref py py-class docutils literal notranslate"><span class="pre">Element</span></code> and <code class="xref py py-class docutils literal notranslate"><span class="pre">Text</span></code>, is a subclass of the
|
||
<code class="xref py py-class docutils literal notranslate"><span class="pre">Node</span></code> base class. All the nodes in a DOM tree therefore support certain
|
||
common methods, such as <code class="xref py py-meth docutils literal notranslate"><span class="pre">toxml()</span></code> which returns a string containing the XML
|
||
representation of the node and its children. Each class also has special
|
||
methods of its own; for example, <code class="xref py py-class docutils literal notranslate"><span class="pre">Element</span></code> and <code class="xref py py-class docutils literal notranslate"><span class="pre">Document</span></code>
|
||
instances have a method to find all child elements with a given tag name.
|
||
Continuing from the previous 2-line example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">perslist</span> <span class="o">=</span> <span class="n">doc</span><span class="o">.</span><span class="n">getElementsByTagName</span><span class="p">(</span> <span class="s1">'PERSONA'</span> <span class="p">)</span>
|
||
<span class="nb">print</span> <span class="n">perslist</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="n">toxml</span><span class="p">()</span>
|
||
<span class="nb">print</span> <span class="n">perslist</span><span class="p">[</span><span class="mi">1</span><span class="p">]</span><span class="o">.</span><span class="n">toxml</span><span class="p">()</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For the <em>Hamlet</em> XML file, the above few lines output:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="o"><</span><span class="n">PERSONA</span><span class="o">></span><span class="n">CLAUDIUS</span><span class="p">,</span> <span class="n">king</span> <span class="n">of</span> <span class="n">Denmark</span><span class="o">.</span> <span class="o"></</span><span class="n">PERSONA</span><span class="o">></span>
|
||
<span class="o"><</span><span class="n">PERSONA</span><span class="o">></span><span class="n">HAMLET</span><span class="p">,</span> <span class="n">son</span> <span class="n">to</span> <span class="n">the</span> <span class="n">late</span><span class="p">,</span> <span class="ow">and</span> <span class="n">nephew</span> <span class="n">to</span> <span class="n">the</span> <span class="n">present</span> <span class="n">king</span><span class="o">.</</span><span class="n">PERSONA</span><span class="o">></span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The root element of the document is available as <code class="docutils literal notranslate"><span class="pre">doc.documentElement</span></code>, and
|
||
its children can be easily modified by deleting, adding, or removing nodes:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">root</span> <span class="o">=</span> <span class="n">doc</span><span class="o">.</span><span class="n">documentElement</span>
|
||
|
||
<span class="c1"># Remove the first child</span>
|
||
<span class="n">root</span><span class="o">.</span><span class="n">removeChild</span><span class="p">(</span> <span class="n">root</span><span class="o">.</span><span class="n">childNodes</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="p">)</span>
|
||
|
||
<span class="c1"># Move the new first child to the end</span>
|
||
<span class="n">root</span><span class="o">.</span><span class="n">appendChild</span><span class="p">(</span> <span class="n">root</span><span class="o">.</span><span class="n">childNodes</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="p">)</span>
|
||
|
||
<span class="c1"># Insert the new first child (originally,</span>
|
||
<span class="c1"># the third child) before the 20th child.</span>
|
||
<span class="n">root</span><span class="o">.</span><span class="n">insertBefore</span><span class="p">(</span> <span class="n">root</span><span class="o">.</span><span class="n">childNodes</span><span class="p">[</span><span class="mi">0</span><span class="p">],</span> <span class="n">root</span><span class="o">.</span><span class="n">childNodes</span><span class="p">[</span><span class="mi">20</span><span class="p">]</span> <span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Again, I will refer you to the Python documentation for a complete listing of
|
||
the different <code class="xref py py-class docutils literal notranslate"><span class="pre">Node</span></code> classes and their various methods.</p>
|
||
</div>
|
||
<div class="section" id="relationship-to-pyxml">
|
||
<h3>Relationship to PyXML<a class="headerlink" href="#relationship-to-pyxml" title="Permalink to this headline">¶</a></h3>
|
||
<p>The XML Special Interest Group has been working on XML-related Python code for a
|
||
while. Its code distribution, called PyXML, is available from the SIG’s Web
|
||
pages at <a class="reference external" href="https://www.python.org/community/sigs/current/xml-sig">https://www.python.org/community/sigs/current/xml-sig</a>. The PyXML distribution also used
|
||
the package name <code class="docutils literal notranslate"><span class="pre">xml</span></code>. If you’ve written programs that used PyXML, you’re
|
||
probably wondering about its compatibility with the 2.0 <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml</span></code></a> package.</p>
|
||
<p>The answer is that Python 2.0’s <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml</span></code></a> package isn’t compatible with PyXML,
|
||
but can be made compatible by installing a recent version PyXML. Many
|
||
applications can get by with the XML support that is included with Python 2.0,
|
||
but more complicated applications will require that the full PyXML package will
|
||
be installed. When installed, PyXML versions 0.6.0 or greater will replace the
|
||
<a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><code class="xref py py-mod docutils literal notranslate"><span class="pre">xml</span></code></a> package shipped with Python, and will be a strict superset of the
|
||
standard package, adding a bunch of additional features. Some of the additional
|
||
features in PyXML include:</p>
|
||
<ul class="simple">
|
||
<li><p>4DOM, a full DOM implementation from FourThought, Inc.</p></li>
|
||
<li><p>The xmlproc validating parser, written by Lars Marius Garshol.</p></li>
|
||
<li><p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">sgmlop</span></code> parser accelerator module, written by Fredrik Lundh.</p></li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="module-changes">
|
||
<h2>Module changes<a class="headerlink" href="#module-changes" title="Permalink to this headline">¶</a></h2>
|
||
<p>Lots of improvements and bugfixes were made to Python’s extensive standard
|
||
library; some of the affected modules include <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">readline</span></code></a>,
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">ConfigParser</span></code>, <a class="reference internal" href="../library/cgi.html#module-cgi" title="cgi: Helpers for running Python scripts via the Common Gateway Interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">cgi</span></code></a>, <a class="reference internal" href="../library/calendar.html#module-calendar" title="calendar: Functions for working with calendars, including some emulation of the Unix cal program."><code class="xref py py-mod docutils literal notranslate"><span class="pre">calendar</span></code></a>, <a class="reference internal" href="../library/posix.html#module-posix" title="posix: The most common POSIX system calls (normally used via module os). (Unix)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">posix</span></code></a>, <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">readline</span></code></a>,
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">xmllib</span></code>, <a class="reference internal" href="../library/aifc.html#module-aifc" title="aifc: Read and write audio files in AIFF or AIFC format."><code class="xref py py-mod docutils literal notranslate"><span class="pre">aifc</span></code></a>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">chunk,</span> <span class="pre">wave</span></code>, <a class="reference internal" href="../library/random.html#module-random" title="random: Generate pseudo-random numbers with various common distributions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">random</span></code></a>, <a class="reference internal" href="../library/shelve.html#module-shelve" title="shelve: Python object persistence."><code class="xref py py-mod docutils literal notranslate"><span class="pre">shelve</span></code></a>,
|
||
and <a class="reference internal" href="../library/nntplib.html#module-nntplib" title="nntplib: NNTP protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">nntplib</span></code></a>. Consult the CVS logs for the exact patch-by-patch details.</p>
|
||
<p>Brian Gallew contributed OpenSSL support for the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">socket</span></code></a> module. OpenSSL
|
||
is an implementation of the Secure Socket Layer, which encrypts the data being
|
||
sent over a socket. When compiling Python, you can edit <code class="file docutils literal notranslate"><span class="pre">Modules/Setup</span></code>
|
||
to include SSL support, which adds an additional function to the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><code class="xref py py-mod docutils literal notranslate"><span class="pre">socket</span></code></a>
|
||
module: <code class="docutils literal notranslate"><span class="pre">socket.ssl(socket,</span> <span class="pre">keyfile,</span> <span class="pre">certfile)</span></code>, which takes a socket
|
||
object and returns an SSL socket. The <code class="xref py py-mod docutils literal notranslate"><span class="pre">httplib</span></code> and <a class="reference internal" href="../library/urllib.html#module-urllib" title="urllib"><code class="xref py py-mod docutils literal notranslate"><span class="pre">urllib</span></code></a> modules
|
||
were also changed to support <code class="docutils literal notranslate"><span class="pre">https://</span></code> URLs, though no one has implemented
|
||
FTP or SMTP over SSL.</p>
|
||
<p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">httplib</span></code> module has been rewritten by Greg Stein to support HTTP/1.1.
|
||
Backward compatibility with the 1.5 version of <code class="xref py py-mod docutils literal notranslate"><span class="pre">httplib</span></code> is provided,
|
||
though using HTTP/1.1 features such as pipelining will require rewriting code to
|
||
use a different set of interfaces.</p>
|
||
<p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">Tkinter</span></code> module now supports Tcl/Tk version 8.1, 8.2, or 8.3, and
|
||
support for the older 7.x versions has been dropped. The Tkinter module now
|
||
supports displaying Unicode strings in Tk widgets. Also, Fredrik Lundh
|
||
contributed an optimization which makes operations like <code class="docutils literal notranslate"><span class="pre">create_line</span></code> and
|
||
<code class="docutils literal notranslate"><span class="pre">create_polygon</span></code> much faster, especially when using lots of coordinates.</p>
|
||
<p>The <a class="reference internal" href="../library/curses.html#module-curses" title="curses: An interface to the curses library, providing portable terminal handling. (Unix)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">curses</span></code></a> module has been greatly extended, starting from Oliver
|
||
Andrich’s enhanced version, to provide many additional functions from ncurses
|
||
and SYSV curses, such as colour, alternative character set support, pads, and
|
||
mouse support. This means the module is no longer compatible with operating
|
||
systems that only have BSD curses, but there don’t seem to be any currently
|
||
maintained OSes that fall into this category.</p>
|
||
<p>As mentioned in the earlier discussion of 2.0’s Unicode support, the underlying
|
||
implementation of the regular expressions provided by the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">re</span></code></a> module has
|
||
been changed. SRE, a new regular expression engine written by Fredrik Lundh and
|
||
partially funded by Hewlett Packard, supports matching against both 8-bit
|
||
strings and Unicode strings.</p>
|
||
</div>
|
||
<div class="section" id="new-modules">
|
||
<h2>New modules<a class="headerlink" href="#new-modules" title="Permalink to this headline">¶</a></h2>
|
||
<p>A number of new modules were added. We’ll simply list them with brief
|
||
descriptions; consult the 2.0 documentation for the details of a particular
|
||
module.</p>
|
||
<ul class="simple">
|
||
<li><p><a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">atexit</span></code></a>: For registering functions to be called before the Python
|
||
interpreter exits. Code that currently sets <code class="docutils literal notranslate"><span class="pre">sys.exitfunc</span></code> directly should be
|
||
changed to use the <a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">atexit</span></code></a> module instead, importing <a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">atexit</span></code></a> and
|
||
calling <a class="reference internal" href="../library/atexit.html#atexit.register" title="atexit.register"><code class="xref py py-func docutils literal notranslate"><span class="pre">atexit.register()</span></code></a> with the function to be called on exit.
|
||
(Contributed by Skip Montanaro.)</p></li>
|
||
<li><p><a class="reference internal" href="../library/codecs.html#module-codecs" title="codecs: Encode and decode data and streams."><code class="xref py py-mod docutils literal notranslate"><span class="pre">codecs</span></code></a>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">encodings</span></code>, <a class="reference internal" href="../library/unicodedata.html#module-unicodedata" title="unicodedata: Access the Unicode Database."><code class="xref py py-mod docutils literal notranslate"><span class="pre">unicodedata</span></code></a>: Added as part of the new
|
||
Unicode support.</p></li>
|
||
<li><p><a class="reference internal" href="../library/filecmp.html#module-filecmp" title="filecmp: Compare files efficiently."><code class="xref py py-mod docutils literal notranslate"><span class="pre">filecmp</span></code></a>: Supersedes the old <code class="xref py py-mod docutils literal notranslate"><span class="pre">cmp</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">cmpcache</span></code> and
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">dircmp</span></code> modules, which have now become deprecated. (Contributed by Gordon
|
||
MacMillan and Moshe Zadka.)</p></li>
|
||
<li><p><a class="reference internal" href="../library/gettext.html#module-gettext" title="gettext: Multilingual internationalization services."><code class="xref py py-mod docutils literal notranslate"><span class="pre">gettext</span></code></a>: This module provides internationalization (I18N) and
|
||
localization (L10N) support for Python programs by providing an interface to the
|
||
GNU gettext message catalog library. (Integrated by Barry Warsaw, from separate
|
||
contributions by Martin von Löwis, Peter Funk, and James Henstridge.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">linuxaudiodev</span></code>: Support for the <code class="file docutils literal notranslate"><span class="pre">/dev/audio</span></code> device on Linux, a
|
||
twin to the existing <code class="xref py py-mod docutils literal notranslate"><span class="pre">sunaudiodev</span></code> module. (Contributed by Peter Bosch,
|
||
with fixes by Jeremy Hylton.)</p></li>
|
||
<li><p><a class="reference internal" href="../library/mmap.html#module-mmap" title="mmap: Interface to memory-mapped files for Unix and Windows."><code class="xref py py-mod docutils literal notranslate"><span class="pre">mmap</span></code></a>: An interface to memory-mapped files on both Windows and Unix. A
|
||
file’s contents can be mapped directly into memory, at which point it behaves
|
||
like a mutable string, so its contents can be read and modified. They can even
|
||
be passed to functions that expect ordinary strings, such as the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><code class="xref py py-mod docutils literal notranslate"><span class="pre">re</span></code></a>
|
||
module. (Contributed by Sam Rushing, with some extensions by A.M. Kuchling.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">pyexpat</span></code>: An interface to the Expat XML parser. (Contributed by Paul
|
||
Prescod.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">robotparser</span></code>: Parse a <code class="file docutils literal notranslate"><span class="pre">robots.txt</span></code> file, which is used for writing
|
||
Web spiders that politely avoid certain areas of a Web site. The parser accepts
|
||
the contents of a <code class="file docutils literal notranslate"><span class="pre">robots.txt</span></code> file, builds a set of rules from it, and
|
||
can then answer questions about the fetchability of a given URL. (Contributed
|
||
by Skip Montanaro.)</p></li>
|
||
<li><p><a class="reference internal" href="../library/tabnanny.html#module-tabnanny" title="tabnanny: Tool for detecting white space related problems in Python source files in a directory tree."><code class="xref py py-mod docutils literal notranslate"><span class="pre">tabnanny</span></code></a>: A module/script to check Python source code for ambiguous
|
||
indentation. (Contributed by Tim Peters.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">UserString</span></code>: A base class useful for deriving objects that behave like
|
||
strings.</p></li>
|
||
<li><p><a class="reference internal" href="../library/webbrowser.html#module-webbrowser" title="webbrowser: Easy-to-use controller for Web browsers."><code class="xref py py-mod docutils literal notranslate"><span class="pre">webbrowser</span></code></a>: A module that provides a platform independent way to launch
|
||
a web browser on a specific URL. For each platform, various browsers are tried
|
||
in a specific order. The user can alter which browser is launched by setting the
|
||
<em>BROWSER</em> environment variable. (Originally inspired by Eric S. Raymond’s patch
|
||
to <a class="reference internal" href="../library/urllib.html#module-urllib" title="urllib"><code class="xref py py-mod docutils literal notranslate"><span class="pre">urllib</span></code></a> which added similar functionality, but the final module comes
|
||
from code originally implemented by Fred Drake as
|
||
<code class="file docutils literal notranslate"><span class="pre">Tools/idle/BrowserControl.py</span></code>, and adapted for the standard library by
|
||
Fred.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">_winreg</span></code>: An interface to the Windows registry. <code class="xref py py-mod docutils literal notranslate"><span class="pre">_winreg</span></code> is an
|
||
adaptation of functions that have been part of PythonWin since 1995, but has now
|
||
been added to the core distribution, and enhanced to support Unicode.
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">_winreg</span></code> was written by Bill Tutt and Mark Hammond.</p></li>
|
||
<li><p><a class="reference internal" href="../library/zipfile.html#module-zipfile" title="zipfile: Read and write ZIP-format archive files."><code class="xref py py-mod docutils literal notranslate"><span class="pre">zipfile</span></code></a>: A module for reading and writing ZIP-format archives. These
|
||
are archives produced by <strong class="program">PKZIP</strong> on DOS/Windows or <strong class="program">zip</strong> on
|
||
Unix, not to be confused with <strong class="program">gzip</strong>-format files (which are
|
||
supported by the <a class="reference internal" href="../library/gzip.html#module-gzip" title="gzip: Interfaces for gzip compression and decompression using file objects."><code class="xref py py-mod docutils literal notranslate"><span class="pre">gzip</span></code></a> module) (Contributed by James C. Ahlstrom.)</p></li>
|
||
<li><p><code class="xref py py-mod docutils literal notranslate"><span class="pre">imputil</span></code>: A module that provides a simpler way for writing customized
|
||
import hooks, in comparison to the existing <code class="xref py py-mod docutils literal notranslate"><span class="pre">ihooks</span></code> module. (Implemented
|
||
by Greg Stein, with much discussion on python-dev along the way.)</p></li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="idle-improvements">
|
||
<h2>IDLE Improvements<a class="headerlink" href="#idle-improvements" title="Permalink to this headline">¶</a></h2>
|
||
<p>IDLE is the official Python cross-platform IDE, written using Tkinter. Python
|
||
2.0 includes IDLE 0.6, which adds a number of new features and improvements. A
|
||
partial list:</p>
|
||
<ul class="simple">
|
||
<li><p>UI improvements and optimizations, especially in the area of syntax
|
||
highlighting and auto-indentation.</p></li>
|
||
<li><p>The class browser now shows more information, such as the top level functions
|
||
in a module.</p></li>
|
||
<li><p>Tab width is now a user settable option. When opening an existing Python file,
|
||
IDLE automatically detects the indentation conventions, and adapts.</p></li>
|
||
<li><p>There is now support for calling browsers on various platforms, used to open
|
||
the Python documentation in a browser.</p></li>
|
||
<li><p>IDLE now has a command line, which is largely similar to the vanilla Python
|
||
interpreter.</p></li>
|
||
<li><p>Call tips were added in many places.</p></li>
|
||
<li><p>IDLE can now be installed as a package.</p></li>
|
||
<li><p>In the editor window, there is now a line/column bar at the bottom.</p></li>
|
||
<li><p>Three new keystroke commands: Check module (<kbd class="kbd docutils literal notranslate">Alt-F5</kbd>), Import module (<kbd class="kbd docutils literal notranslate">F5</kbd>) and
|
||
Run script (<kbd class="kbd docutils literal notranslate">Ctrl-F5</kbd>).</p></li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="deleted-and-deprecated-modules">
|
||
<h2>Deleted and Deprecated Modules<a class="headerlink" href="#deleted-and-deprecated-modules" title="Permalink to this headline">¶</a></h2>
|
||
<p>A few modules have been dropped because they’re obsolete, or because there are
|
||
now better ways to do the same thing. The <code class="xref py py-mod docutils literal notranslate"><span class="pre">stdwin</span></code> module is gone; it was
|
||
for a platform-independent windowing toolkit that’s no longer developed.</p>
|
||
<p>A number of modules have been moved to the <code class="file docutils literal notranslate"><span class="pre">lib-old</span></code> subdirectory:
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">cmp</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">cmpcache</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">dircmp</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">dump</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">find</span></code>,
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">grep</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">packmail</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">poly</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">util</span></code>, <code class="xref py py-mod docutils literal notranslate"><span class="pre">whatsound</span></code>,
|
||
<code class="xref py py-mod docutils literal notranslate"><span class="pre">zmod</span></code>. If you have code which relies on a module that’s been moved to
|
||
<code class="file docutils literal notranslate"><span class="pre">lib-old</span></code>, you can simply add that directory to <code class="docutils literal notranslate"><span class="pre">sys.path</span></code> to get them
|
||
back, but you’re encouraged to update any code that uses these modules.</p>
|
||
</div>
|
||
<div class="section" id="acknowledgements">
|
||
<h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Permalink to this headline">¶</a></h2>
|
||
<p>The authors would like to thank the following people for offering suggestions on
|
||
various drafts of this article: David Bolen, Mark Hammond, Gregg Hauser, Jeremy
|
||
Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir
|
||
Marangozov, Tobias Polzin, Guido van Rossum, Neil Schemenauer, and Russ Schmidt.</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="#">What’s New in Python 2.0</a><ul>
|
||
<li><a class="reference internal" href="#introduction">Introduction</a></li>
|
||
<li><a class="reference internal" href="#what-about-python-1-6">What About Python 1.6?</a></li>
|
||
<li><a class="reference internal" href="#new-development-process">New Development Process</a></li>
|
||
<li><a class="reference internal" href="#unicode">Unicode</a></li>
|
||
<li><a class="reference internal" href="#list-comprehensions">List Comprehensions</a></li>
|
||
<li><a class="reference internal" href="#augmented-assignment">Augmented Assignment</a></li>
|
||
<li><a class="reference internal" href="#string-methods">String Methods</a></li>
|
||
<li><a class="reference internal" href="#garbage-collection-of-cycles">Garbage Collection of Cycles</a></li>
|
||
<li><a class="reference internal" href="#other-core-changes">Other Core Changes</a><ul>
|
||
<li><a class="reference internal" href="#minor-language-changes">Minor Language Changes</a></li>
|
||
<li><a class="reference internal" href="#changes-to-built-in-functions">Changes to Built-in Functions</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#porting-to-2-0">Porting to 2.0</a></li>
|
||
<li><a class="reference internal" href="#extending-embedding-changes">Extending/Embedding Changes</a></li>
|
||
<li><a class="reference internal" href="#distutils-making-modules-easy-to-install">Distutils: Making Modules Easy to Install</a></li>
|
||
<li><a class="reference internal" href="#xml-modules">XML Modules</a><ul>
|
||
<li><a class="reference internal" href="#sax2-support">SAX2 Support</a></li>
|
||
<li><a class="reference internal" href="#dom-support">DOM Support</a></li>
|
||
<li><a class="reference internal" href="#relationship-to-pyxml">Relationship to PyXML</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#module-changes">Module changes</a></li>
|
||
<li><a class="reference internal" href="#new-modules">New modules</a></li>
|
||
<li><a class="reference internal" href="#idle-improvements">IDLE Improvements</a></li>
|
||
<li><a class="reference internal" href="#deleted-and-deprecated-modules">Deleted and Deprecated Modules</a></li>
|
||
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<h4>Previous topic</h4>
|
||
<p class="topless"><a href="2.1.html"
|
||
title="previous chapter">What’s New in Python 2.1</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="changelog.html"
|
||
title="next chapter">Changelog</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/whatsnew/2.0.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="changelog.html" title="Changelog"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="2.1.html" title="What’s New in Python 2.1"
|
||
>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" >What’s New in Python</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> |