1303 lines
135 KiB
HTML
1303 lines
135 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<title>What’s New in Python 2.2 — 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="What’s New in Python 2.1" href="2.1.html" />
|
||
<link rel="prev" title="What’s New in Python 2.3" href="2.3.html" />
|
||
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
|
||
<link rel="canonical" href="https://docs.python.org/3/whatsnew/2.2.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="2.1.html" title="What’s New in Python 2.1"
|
||
accesskey="N">next</a> |</li>
|
||
<li class="right" >
|
||
<a href="2.3.html" title="What’s New in Python 2.3"
|
||
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-2">
|
||
<h1>What’s New in Python 2.2<a class="headerlink" href="#what-s-new-in-python-2-2" 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</p>
|
||
</dd>
|
||
</dl>
|
||
<div class="section" id="introduction">
|
||
<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
|
||
<p>This article explains the new features in Python 2.2.2, released on October 14,
|
||
2002. Python 2.2.2 is a bugfix release of Python 2.2, originally released on
|
||
December 21, 2001.</p>
|
||
<p>Python 2.2 can be thought of as the “cleanup release”. There are some features
|
||
such as generators and iterators that are completely new, but most of the
|
||
changes, significant and far-reaching though they may be, are aimed at cleaning
|
||
up irregularities and dark corners of the language design.</p>
|
||
<p>This article doesn’t attempt to provide a complete specification of the new
|
||
features, but instead provides a convenient overview. For full details, you
|
||
should refer to the documentation for Python 2.2, such as the <a class="reference external" href="https://docs.python.org/2.2/lib/lib.html">Python Library
|
||
Reference</a> and the <a class="reference external" href="https://docs.python.org/2.2/ref/ref.html">Python
|
||
Reference Manual</a>. If you want to
|
||
understand the complete implementation and design rationale for a change, refer
|
||
to the PEP for a particular new feature.</p>
|
||
</div>
|
||
<div class="section" id="peps-252-and-253-type-and-class-changes">
|
||
<h2>PEPs 252 and 253: Type and Class Changes<a class="headerlink" href="#peps-252-and-253-type-and-class-changes" title="Permalink to this headline">¶</a></h2>
|
||
<p>The largest and most far-reaching changes in Python 2.2 are to Python’s model of
|
||
objects and classes. The changes should be backward compatible, so it’s likely
|
||
that your code will continue to run unchanged, but the changes provide some
|
||
amazing new capabilities. Before beginning this, the longest and most
|
||
complicated section of this article, I’ll provide an overview of the changes and
|
||
offer some comments.</p>
|
||
<p>A long time ago I wrote a Web page listing flaws in Python’s design. One of the
|
||
most significant flaws was that it’s impossible to subclass Python types
|
||
implemented in C. In particular, it’s not possible to subclass built-in types,
|
||
so you can’t just subclass, say, lists in order to add a single useful method to
|
||
them. The <code class="xref py py-mod docutils literal notranslate"><span class="pre">UserList</span></code> module provides a class that supports all of the
|
||
methods of lists and that can be subclassed further, but there’s lots of C code
|
||
that expects a regular Python list and won’t accept a <code class="xref py py-class docutils literal notranslate"><span class="pre">UserList</span></code>
|
||
instance.</p>
|
||
<p>Python 2.2 fixes this, and in the process adds some exciting new capabilities.
|
||
A brief summary:</p>
|
||
<ul class="simple">
|
||
<li><p>You can subclass built-in types such as lists and even integers, and your
|
||
subclasses should work in every place that requires the original type.</p></li>
|
||
<li><p>It’s now possible to define static and class methods, in addition to the
|
||
instance methods available in previous versions of Python.</p></li>
|
||
<li><p>It’s also possible to automatically call methods on accessing or setting an
|
||
instance attribute by using a new mechanism called <em class="dfn">properties</em>. Many uses
|
||
of <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a> can be rewritten to use properties instead, making the
|
||
resulting code simpler and faster. As a small side benefit, attributes can now
|
||
have docstrings, too.</p></li>
|
||
<li><p>The list of legal attributes for an instance can be limited to a particular
|
||
set using <em class="dfn">slots</em>, making it possible to safeguard against typos and
|
||
perhaps make more optimizations possible in future versions of Python.</p></li>
|
||
</ul>
|
||
<p>Some users have voiced concern about all these changes. Sure, they say, the new
|
||
features are neat and lend themselves to all sorts of tricks that weren’t
|
||
possible in previous versions of Python, but they also make the language more
|
||
complicated. Some people have said that they’ve always recommended Python for
|
||
its simplicity, and feel that its simplicity is being lost.</p>
|
||
<p>Personally, I think there’s no need to worry. Many of the new features are
|
||
quite esoteric, and you can write a lot of Python code without ever needed to be
|
||
aware of them. Writing a simple class is no more difficult than it ever was, so
|
||
you don’t need to bother learning or teaching them unless they’re actually
|
||
needed. Some very complicated tasks that were previously only possible from C
|
||
will now be possible in pure Python, and to my mind that’s all for the better.</p>
|
||
<p>I’m not going to attempt to cover every single corner case and small change that
|
||
were required to make the new features work. Instead this section will paint
|
||
only the broad strokes. See section <a class="reference internal" href="#sect-rellinks"><span class="std std-ref">Related Links</span></a>, “Related Links”, for
|
||
further sources of information about Python 2.2’s new object model.</p>
|
||
<div class="section" id="old-and-new-classes">
|
||
<h3>Old and New Classes<a class="headerlink" href="#old-and-new-classes" title="Permalink to this headline">¶</a></h3>
|
||
<p>First, you should know that Python 2.2 really has two kinds of classes: classic
|
||
or old-style classes, and new-style classes. The old-style class model is
|
||
exactly the same as the class model in earlier versions of Python. All the new
|
||
features described in this section apply only to new-style classes. This
|
||
divergence isn’t intended to last forever; eventually old-style classes will be
|
||
dropped, possibly in Python 3.0.</p>
|
||
<p>So how do you define a new-style class? You do it by subclassing an existing
|
||
new-style class. Most of Python’s built-in types, such as integers, lists,
|
||
dictionaries, and even files, are new-style classes now. A new-style class
|
||
named <a class="reference internal" href="../library/functions.html#object" title="object"><code class="xref py py-class docutils literal notranslate"><span class="pre">object</span></code></a>, the base class for all built-in types, has also been
|
||
added so if no built-in type is suitable, you can just subclass
|
||
<a class="reference internal" href="../library/functions.html#object" title="object"><code class="xref py py-class docutils literal notranslate"><span class="pre">object</span></code></a>:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">(</span><span class="nb">object</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="o">...</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>This means that <a class="reference internal" href="../reference/compound_stmts.html#class"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">class</span></code></a> statements that don’t have any base classes are
|
||
always classic classes in Python 2.2. (Actually you can also change this by
|
||
setting a module-level variable named <code class="xref py py-attr docutils literal notranslate"><span class="pre">__metaclass__</span></code> — see <span class="target" id="index-0"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0253"><strong>PEP 253</strong></a>
|
||
for the details — but it’s easier to just subclass <a class="reference internal" href="../library/functions.html#object" title="object"><code class="xref py py-class docutils literal notranslate"><span class="pre">object</span></code></a>.)</p>
|
||
<p>The type objects for the built-in types are available as built-ins, named using
|
||
a clever trick. Python has always had built-in functions named <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>,
|
||
<a class="reference internal" href="../library/functions.html#float" title="float"><code class="xref py py-func docutils literal notranslate"><span class="pre">float()</span></code></a>, and <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>. In 2.2, they aren’t functions any more, but
|
||
type objects that behave as factories when called.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="nb">int</span>
|
||
<span class="go"><type 'int'></span>
|
||
<span class="gp">>>> </span><span class="nb">int</span><span class="p">(</span><span class="s1">'123'</span><span class="p">)</span>
|
||
<span class="go">123</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>To make the set of types complete, new type objects such as <a class="reference internal" href="../library/stdtypes.html#dict" title="dict"><code class="xref py py-func docutils literal notranslate"><span class="pre">dict()</span></code></a> and
|
||
<code class="xref py py-func docutils literal notranslate"><span class="pre">file()</span></code> have been added. Here’s a more interesting example, adding a
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">lock()</span></code> method to file objects:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">LockableFile</span><span class="p">(</span><span class="n">file</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">lock</span> <span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">operation</span><span class="p">,</span> <span class="n">length</span><span class="o">=</span><span class="mi">0</span><span class="p">,</span> <span class="n">start</span><span class="o">=</span><span class="mi">0</span><span class="p">,</span> <span class="n">whence</span><span class="o">=</span><span class="mi">0</span><span class="p">):</span>
|
||
<span class="kn">import</span> <span class="nn">fcntl</span>
|
||
<span class="k">return</span> <span class="n">fcntl</span><span class="o">.</span><span class="n">lockf</span><span class="p">(</span><span class="bp">self</span><span class="o">.</span><span class="n">fileno</span><span class="p">(),</span> <span class="n">operation</span><span class="p">,</span>
|
||
<span class="n">length</span><span class="p">,</span> <span class="n">start</span><span class="p">,</span> <span class="n">whence</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The now-obsolete <code class="xref py py-mod docutils literal notranslate"><span class="pre">posixfile</span></code> module contained a class that emulated all of
|
||
a file object’s methods and also added a <code class="xref py py-meth docutils literal notranslate"><span class="pre">lock()</span></code> method, but this class
|
||
couldn’t be passed to internal functions that expected a built-in file,
|
||
something which is possible with our new <code class="xref py py-class docutils literal notranslate"><span class="pre">LockableFile</span></code>.</p>
|
||
</div>
|
||
<div class="section" id="descriptors">
|
||
<h3>Descriptors<a class="headerlink" href="#descriptors" title="Permalink to this headline">¶</a></h3>
|
||
<p>In previous versions of Python, there was no consistent way to discover what
|
||
attributes and methods were supported by an object. There were some informal
|
||
conventions, such as defining <code class="xref py py-attr docutils literal notranslate"><span class="pre">__members__</span></code> and <code class="xref py py-attr docutils literal notranslate"><span class="pre">__methods__</span></code>
|
||
attributes that were lists of names, but often the author of an extension type
|
||
or a class wouldn’t bother to define them. You could fall back on inspecting
|
||
the <a class="reference internal" href="../library/stdtypes.html#object.__dict__" title="object.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a> of an object, but when class inheritance or an arbitrary
|
||
<a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a> hook were in use this could still be inaccurate.</p>
|
||
<p>The one big idea underlying the new class model is that an API for describing
|
||
the attributes of an object using <em class="dfn">descriptors</em> has been formalized.
|
||
Descriptors specify the value of an attribute, stating whether it’s a method or
|
||
a field. With the descriptor API, static methods and class methods become
|
||
possible, as well as more exotic constructs.</p>
|
||
<p>Attribute descriptors are objects that live inside class objects, and have a few
|
||
attributes of their own:</p>
|
||
<ul class="simple">
|
||
<li><p><a class="reference internal" href="../library/stdtypes.html#definition.__name__" title="definition.__name__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__name__</span></code></a> is the attribute’s name.</p></li>
|
||
<li><p><code class="xref py py-attr docutils literal notranslate"><span class="pre">__doc__</span></code> is the attribute’s docstring.</p></li>
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">__get__(object)</span></code> is a method that retrieves the attribute value from
|
||
<em>object</em>.</p></li>
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">__set__(object,</span> <span class="pre">value)</span></code> sets the attribute on <em>object</em> to <em>value</em>.</p></li>
|
||
<li><p><code class="docutils literal notranslate"><span class="pre">__delete__(object,</span> <span class="pre">value)</span></code> deletes the <em>value</em> attribute of <em>object</em>.</p></li>
|
||
</ul>
|
||
<p>For example, when you write <code class="docutils literal notranslate"><span class="pre">obj.x</span></code>, the steps that Python actually performs
|
||
are:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">descriptor</span> <span class="o">=</span> <span class="n">obj</span><span class="o">.</span><span class="vm">__class__</span><span class="o">.</span><span class="n">x</span>
|
||
<span class="n">descriptor</span><span class="o">.</span><span class="fm">__get__</span><span class="p">(</span><span class="n">obj</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>For methods, <code class="xref py py-meth docutils literal notranslate"><span class="pre">descriptor.__get__()</span></code> returns a temporary object that’s
|
||
callable, and wraps up the instance and the method to be called on it. This is
|
||
also why static methods and class methods are now possible; they have
|
||
descriptors that wrap up just the method, or the method and the class. As a
|
||
brief explanation of these new kinds of methods, static methods aren’t passed
|
||
the instance, and therefore resemble regular functions. Class methods are
|
||
passed the class of the object, but not the object itself. Static and class
|
||
methods are defined like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">f</span><span class="p">(</span><span class="n">arg1</span><span class="p">,</span> <span class="n">arg2</span><span class="p">):</span>
|
||
<span class="o">...</span>
|
||
<span class="n">f</span> <span class="o">=</span> <span class="nb">staticmethod</span><span class="p">(</span><span class="n">f</span><span class="p">)</span>
|
||
|
||
<span class="k">def</span> <span class="nf">g</span><span class="p">(</span><span class="bp">cls</span><span class="p">,</span> <span class="n">arg1</span><span class="p">,</span> <span class="n">arg2</span><span class="p">):</span>
|
||
<span class="o">...</span>
|
||
<span class="n">g</span> <span class="o">=</span> <span class="nb">classmethod</span><span class="p">(</span><span class="n">g</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <a class="reference internal" href="../library/functions.html#staticmethod" title="staticmethod"><code class="xref py py-func docutils literal notranslate"><span class="pre">staticmethod()</span></code></a> function takes the function <code class="xref py py-func docutils literal notranslate"><span class="pre">f()</span></code>, and returns it
|
||
wrapped up in a descriptor so it can be stored in the class object. You might
|
||
expect there to be special syntax for creating such methods (<code class="docutils literal notranslate"><span class="pre">def</span> <span class="pre">static</span> <span class="pre">f</span></code>,
|
||
<code class="docutils literal notranslate"><span class="pre">defstatic</span> <span class="pre">f()</span></code>, or something like that) but no such syntax has been defined
|
||
yet; that’s been left for future versions of Python.</p>
|
||
<p>More new features, such as slots and properties, are also implemented as new
|
||
kinds of descriptors, and it’s not difficult to write a descriptor class that
|
||
does something novel. For example, it would be possible to write a descriptor
|
||
class that made it possible to write Eiffel-style preconditions and
|
||
postconditions for a method. A class that used this feature might be defined
|
||
like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">eiffel</span> <span class="k">import</span> <span class="n">eiffelmethod</span>
|
||
|
||
<span class="k">class</span> <span class="nc">C</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">f</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">arg1</span><span class="p">,</span> <span class="n">arg2</span><span class="p">):</span>
|
||
<span class="c1"># The actual function</span>
|
||
<span class="o">...</span>
|
||
<span class="k">def</span> <span class="nf">pre_f</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="c1"># Check preconditions</span>
|
||
<span class="o">...</span>
|
||
<span class="k">def</span> <span class="nf">post_f</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="c1"># Check postconditions</span>
|
||
<span class="o">...</span>
|
||
|
||
<span class="n">f</span> <span class="o">=</span> <span class="n">eiffelmethod</span><span class="p">(</span><span class="n">f</span><span class="p">,</span> <span class="n">pre_f</span><span class="p">,</span> <span class="n">post_f</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Note that a person using the new <code class="xref py py-func docutils literal notranslate"><span class="pre">eiffelmethod()</span></code> doesn’t have to understand
|
||
anything about descriptors. This is why I think the new features don’t increase
|
||
the basic complexity of the language. There will be a few wizards who need to
|
||
know about it in order to write <code class="xref py py-func docutils literal notranslate"><span class="pre">eiffelmethod()</span></code> or the ZODB or whatever,
|
||
but most users will just write code on top of the resulting libraries and ignore
|
||
the implementation details.</p>
|
||
</div>
|
||
<div class="section" id="multiple-inheritance-the-diamond-rule">
|
||
<h3>Multiple Inheritance: The Diamond Rule<a class="headerlink" href="#multiple-inheritance-the-diamond-rule" title="Permalink to this headline">¶</a></h3>
|
||
<p>Multiple inheritance has also been made more useful through changing the rules
|
||
under which names are resolved. Consider this set of classes (diagram taken
|
||
from <span class="target" id="index-1"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0253"><strong>PEP 253</strong></a> by Guido van Rossum):</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span> <span class="k">class</span> <span class="nc">A</span><span class="p">:</span>
|
||
<span class="o">^</span> <span class="o">^</span> <span class="k">def</span> <span class="nf">save</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="o">...</span>
|
||
<span class="o">/</span> \
|
||
<span class="o">/</span> \
|
||
<span class="o">/</span> \
|
||
<span class="o">/</span> \
|
||
<span class="k">class</span> <span class="nc">B</span> <span class="k">class</span> <span class="nc">C</span><span class="p">:</span>
|
||
<span class="o">^</span> <span class="o">^</span> <span class="k">def</span> <span class="nf">save</span><span class="p">(</span><span class="bp">self</span><span class="p">):</span> <span class="o">...</span>
|
||
\ <span class="o">/</span>
|
||
\ <span class="o">/</span>
|
||
\ <span class="o">/</span>
|
||
\ <span class="o">/</span>
|
||
<span class="k">class</span> <span class="nc">D</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The lookup rule for classic classes is simple but not very smart; the base
|
||
classes are searched depth-first, going from left to right. A reference to
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">D.save()</span></code> will search the classes <code class="xref py py-class docutils literal notranslate"><span class="pre">D</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">B</span></code>, and then
|
||
<code class="xref py py-class docutils literal notranslate"><span class="pre">A</span></code>, where <code class="xref py py-meth docutils literal notranslate"><span class="pre">save()</span></code> would be found and returned. <code class="xref py py-meth docutils literal notranslate"><span class="pre">C.save()</span></code>
|
||
would never be found at all. This is bad, because if <code class="xref py py-class docutils literal notranslate"><span class="pre">C</span></code>’s <code class="xref py py-meth docutils literal notranslate"><span class="pre">save()</span></code>
|
||
method is saving some internal state specific to <code class="xref py py-class docutils literal notranslate"><span class="pre">C</span></code>, not calling it will
|
||
result in that state never getting saved.</p>
|
||
<p>New-style classes follow a different algorithm that’s a bit more complicated to
|
||
explain, but does the right thing in this situation. (Note that Python 2.3
|
||
changes this algorithm to one that produces the same results in most cases, but
|
||
produces more useful results for really complicated inheritance graphs.)</p>
|
||
<ol class="arabic simple">
|
||
<li><p>List all the base classes, following the classic lookup rule and include a
|
||
class multiple times if it’s visited repeatedly. In the above example, the list
|
||
of visited classes is [<code class="xref py py-class docutils literal notranslate"><span class="pre">D</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">B</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">A</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">C</span></code>,
|
||
<code class="xref py py-class docutils literal notranslate"><span class="pre">A</span></code>].</p></li>
|
||
<li><p>Scan the list for duplicated classes. If any are found, remove all but one
|
||
occurrence, leaving the <em>last</em> one in the list. In the above example, the list
|
||
becomes [<code class="xref py py-class docutils literal notranslate"><span class="pre">D</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">B</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">C</span></code>, <code class="xref py py-class docutils literal notranslate"><span class="pre">A</span></code>] after dropping
|
||
duplicates.</p></li>
|
||
</ol>
|
||
<p>Following this rule, referring to <code class="xref py py-meth docutils literal notranslate"><span class="pre">D.save()</span></code> will return <code class="xref py py-meth docutils literal notranslate"><span class="pre">C.save()</span></code>,
|
||
which is the behaviour we’re after. This lookup rule is the same as the one
|
||
followed by Common Lisp. A new built-in function, <a class="reference internal" href="../library/functions.html#super" title="super"><code class="xref py py-func docutils literal notranslate"><span class="pre">super()</span></code></a>, provides a way
|
||
to get at a class’s superclasses without having to reimplement Python’s
|
||
algorithm. The most commonly used form will be <code class="docutils literal notranslate"><span class="pre">super(class,</span> <span class="pre">obj)</span></code>, which
|
||
returns a bound superclass object (not the actual class object). This form
|
||
will be used in methods to call a method in the superclass; for example,
|
||
<code class="xref py py-class docutils literal notranslate"><span class="pre">D</span></code>’s <code class="xref py py-meth docutils literal notranslate"><span class="pre">save()</span></code> method would look like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">D</span> <span class="p">(</span><span class="n">B</span><span class="p">,</span><span class="n">C</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">save</span> <span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="c1"># Call superclass .save()</span>
|
||
<span class="nb">super</span><span class="p">(</span><span class="n">D</span><span class="p">,</span> <span class="bp">self</span><span class="p">)</span><span class="o">.</span><span class="n">save</span><span class="p">()</span>
|
||
<span class="c1"># Save D's private information here</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p><a class="reference internal" href="../library/functions.html#super" title="super"><code class="xref py py-func docutils literal notranslate"><span class="pre">super()</span></code></a> can also return unbound superclass objects when called as
|
||
<code class="docutils literal notranslate"><span class="pre">super(class)</span></code> or <code class="docutils literal notranslate"><span class="pre">super(class1,</span> <span class="pre">class2)</span></code>, but this probably won’t
|
||
often be useful.</p>
|
||
</div>
|
||
<div class="section" id="attribute-access">
|
||
<h3>Attribute Access<a class="headerlink" href="#attribute-access" title="Permalink to this headline">¶</a></h3>
|
||
<p>A fair number of sophisticated Python classes define hooks for attribute access
|
||
using <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a>; most commonly this is done for convenience, to make
|
||
code more readable by automatically mapping an attribute access such as
|
||
<code class="docutils literal notranslate"><span class="pre">obj.parent</span></code> into a method call such as <code class="docutils literal notranslate"><span class="pre">obj.get_parent</span></code>. Python 2.2 adds
|
||
some new ways of controlling attribute access.</p>
|
||
<p>First, <code class="docutils literal notranslate"><span class="pre">__getattr__(attr_name)</span></code> is still supported by new-style classes,
|
||
and nothing about it has changed. As before, it will be called when an attempt
|
||
is made to access <code class="docutils literal notranslate"><span class="pre">obj.foo</span></code> and no attribute named <code class="docutils literal notranslate"><span class="pre">foo</span></code> is found in the
|
||
instance’s dictionary.</p>
|
||
<p>New-style classes also support a new method,
|
||
<code class="docutils literal notranslate"><span class="pre">__getattribute__(attr_name)</span></code>. The difference between the two methods is
|
||
that <a class="reference internal" href="../reference/datamodel.html#object.__getattribute__" title="object.__getattribute__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattribute__()</span></code></a> is <em>always</em> called whenever any attribute is
|
||
accessed, while the old <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a> is only called if <code class="docutils literal notranslate"><span class="pre">foo</span></code> isn’t
|
||
found in the instance’s dictionary.</p>
|
||
<p>However, Python 2.2’s support for <em class="dfn">properties</em> will often be a simpler way
|
||
to trap attribute references. Writing a <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a> method is
|
||
complicated because to avoid recursion you can’t use regular attribute accesses
|
||
inside them, and instead have to mess around with the contents of
|
||
<a class="reference internal" href="../library/stdtypes.html#object.__dict__" title="object.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a>. <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a> methods also end up being called by Python
|
||
when it checks for other methods such as <a class="reference internal" href="../reference/datamodel.html#object.__repr__" title="object.__repr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__repr__()</span></code></a> or <code class="xref py py-meth docutils literal notranslate"><span class="pre">__coerce__()</span></code>,
|
||
and so have to be written with this in mind. Finally, calling a function on
|
||
every attribute access results in a sizable performance loss.</p>
|
||
<p><a class="reference internal" href="../library/functions.html#property" title="property"><code class="xref py py-class docutils literal notranslate"><span class="pre">property</span></code></a> is a new built-in type that packages up three functions that
|
||
get, set, or delete an attribute, and a docstring. For example, if you want to
|
||
define a <code class="xref py py-attr docutils literal notranslate"><span class="pre">size</span></code> attribute that’s computed, but also settable, you could
|
||
write:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">class</span> <span class="nc">C</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
|
||
<span class="k">def</span> <span class="nf">get_size</span> <span class="p">(</span><span class="bp">self</span><span class="p">):</span>
|
||
<span class="n">result</span> <span class="o">=</span> <span class="o">...</span> <span class="n">computation</span> <span class="o">...</span>
|
||
<span class="k">return</span> <span class="n">result</span>
|
||
<span class="k">def</span> <span class="nf">set_size</span> <span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">size</span><span class="p">):</span>
|
||
<span class="o">...</span> <span class="n">compute</span> <span class="n">something</span> <span class="n">based</span> <span class="n">on</span> <span class="n">the</span> <span class="n">size</span>
|
||
<span class="ow">and</span> <span class="nb">set</span> <span class="n">internal</span> <span class="n">state</span> <span class="n">appropriately</span> <span class="o">...</span>
|
||
|
||
<span class="c1"># Define a property. The 'delete this attribute'</span>
|
||
<span class="c1"># method is defined as None, so the attribute</span>
|
||
<span class="c1"># can't be deleted.</span>
|
||
<span class="n">size</span> <span class="o">=</span> <span class="nb">property</span><span class="p">(</span><span class="n">get_size</span><span class="p">,</span> <span class="n">set_size</span><span class="p">,</span>
|
||
<span class="kc">None</span><span class="p">,</span>
|
||
<span class="s2">"Storage size of this instance"</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>That is certainly clearer and easier to write than a pair of
|
||
<a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getattr__()</span></code></a>/<a class="reference internal" href="../reference/datamodel.html#object.__setattr__" title="object.__setattr__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__setattr__()</span></code></a> methods that check for the <code class="xref py py-attr docutils literal notranslate"><span class="pre">size</span></code>
|
||
attribute and handle it specially while retrieving all other attributes from the
|
||
instance’s <a class="reference internal" href="../library/stdtypes.html#object.__dict__" title="object.__dict__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__dict__</span></code></a>. Accesses to <code class="xref py py-attr docutils literal notranslate"><span class="pre">size</span></code> are also the only ones
|
||
which have to perform the work of calling a function, so references to other
|
||
attributes run at their usual speed.</p>
|
||
<p>Finally, it’s possible to constrain the list of attributes that can be
|
||
referenced on an object using the new <a class="reference internal" href="../reference/datamodel.html#object.__slots__" title="object.__slots__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code></a> class attribute. Python
|
||
objects are usually very dynamic; at any time it’s possible to define a new
|
||
attribute on an instance by just doing <code class="docutils literal notranslate"><span class="pre">obj.new_attr=1</span></code>. A new-style class
|
||
can define a class attribute named <a class="reference internal" href="../reference/datamodel.html#object.__slots__" title="object.__slots__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code></a> to limit the legal
|
||
attributes to a particular set of names. An example will make this clear:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="k">class</span> <span class="nc">C</span><span class="p">(</span><span class="nb">object</span><span class="p">):</span>
|
||
<span class="gp">... </span> <span class="vm">__slots__</span> <span class="o">=</span> <span class="p">(</span><span class="s1">'template'</span><span class="p">,</span> <span class="s1">'name'</span><span class="p">)</span>
|
||
<span class="gp">...</span>
|
||
<span class="gp">>>> </span><span class="n">obj</span> <span class="o">=</span> <span class="n">C</span><span class="p">()</span>
|
||
<span class="gp">>>> </span><span class="nb">print</span> <span class="n">obj</span><span class="o">.</span><span class="n">template</span>
|
||
<span class="go">None</span>
|
||
<span class="gp">>>> </span><span class="n">obj</span><span class="o">.</span><span class="n">template</span> <span class="o">=</span> <span class="s1">'Test'</span>
|
||
<span class="gp">>>> </span><span class="nb">print</span> <span class="n">obj</span><span class="o">.</span><span class="n">template</span>
|
||
<span class="go">Test</span>
|
||
<span class="gp">>>> </span><span class="n">obj</span><span class="o">.</span><span class="n">newattr</span> <span class="o">=</span> <span class="kc">None</span>
|
||
<span class="gt">Traceback (most recent call last):</span>
|
||
File <span class="nb">"<stdin>"</span>, line <span class="m">1</span>, in <span class="n">?</span>
|
||
<span class="gr">AttributeError</span>: <span class="n">'C' object has no attribute 'newattr'</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Note how you get an <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> on the attempt to assign to an
|
||
attribute not listed in <a class="reference internal" href="../reference/datamodel.html#object.__slots__" title="object.__slots__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code></a>.</p>
|
||
</div>
|
||
<div class="section" id="related-links">
|
||
<span id="sect-rellinks"></span><h3>Related Links<a class="headerlink" href="#related-links" title="Permalink to this headline">¶</a></h3>
|
||
<p>This section has just been a quick overview of the new features, giving enough
|
||
of an explanation to start you programming, but many details have been
|
||
simplified or ignored. Where should you go to get a more complete picture?</p>
|
||
<p><a class="reference external" href="https://docs.python.org/dev/howto/descriptor.html">https://docs.python.org/dev/howto/descriptor.html</a> is a lengthy tutorial introduction to
|
||
the descriptor features, written by Guido van Rossum. If my description has
|
||
whetted your appetite, go read this tutorial next, because it goes into much
|
||
more detail about the new features while still remaining quite easy to read.</p>
|
||
<p>Next, there are two relevant PEPs, <span class="target" id="index-2"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0252"><strong>PEP 252</strong></a> and <span class="target" id="index-3"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0253"><strong>PEP 253</strong></a>. <span class="target" id="index-4"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0252"><strong>PEP 252</strong></a> is
|
||
titled “Making Types Look More Like Classes”, and covers the descriptor API.
|
||
<span class="target" id="index-5"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0253"><strong>PEP 253</strong></a> is titled “Subtyping Built-in Types”, and describes the changes to
|
||
type objects that make it possible to subtype built-in objects. <span class="target" id="index-6"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0253"><strong>PEP 253</strong></a> is
|
||
the more complicated PEP of the two, and at a few points the necessary
|
||
explanations of types and meta-types may cause your head to explode. Both PEPs
|
||
were written and implemented by Guido van Rossum, with substantial assistance
|
||
from the rest of the Zope Corp. team.</p>
|
||
<p>Finally, there’s the ultimate authority: the source code. Most of the machinery
|
||
for the type handling is in <code class="file docutils literal notranslate"><span class="pre">Objects/typeobject.c</span></code>, but you should only
|
||
resort to it after all other avenues have been exhausted, including posting a
|
||
question to python-list or python-dev.</p>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="pep-234-iterators">
|
||
<h2>PEP 234: Iterators<a class="headerlink" href="#pep-234-iterators" title="Permalink to this headline">¶</a></h2>
|
||
<p>Another significant addition to 2.2 is an iteration interface at both the C and
|
||
Python levels. Objects can define how they can be looped over by callers.</p>
|
||
<p>In Python versions up to 2.1, the usual way to make <code class="docutils literal notranslate"><span class="pre">for</span> <span class="pre">item</span> <span class="pre">in</span> <span class="pre">obj</span></code> work is
|
||
to define a <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getitem__()</span></code></a> method that looks something like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">__getitem__</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">index</span><span class="p">):</span>
|
||
<span class="k">return</span> <span class="o"><</span><span class="nb">next</span> <span class="n">item</span><span class="o">></span>
|
||
</pre></div>
|
||
</div>
|
||
<p><a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getitem__()</span></code></a> is more properly used to define an indexing operation on an
|
||
object so that you can write <code class="docutils literal notranslate"><span class="pre">obj[5]</span></code> to retrieve the sixth element. It’s a
|
||
bit misleading when you’re using this only to support <a class="reference internal" href="../reference/compound_stmts.html#for"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">for</span></code></a> loops.
|
||
Consider some file-like object that wants to be looped over; the <em>index</em>
|
||
parameter is essentially meaningless, as the class probably assumes that a
|
||
series of <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getitem__()</span></code></a> calls will be made with <em>index</em> incrementing by
|
||
one each time. In other words, the presence of the <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getitem__()</span></code></a> method
|
||
doesn’t mean that using <code class="docutils literal notranslate"><span class="pre">file[5]</span></code> to randomly access the sixth element will
|
||
work, though it really should.</p>
|
||
<p>In Python 2.2, iteration can be implemented separately, and <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__getitem__()</span></code></a>
|
||
methods can be limited to classes that really do support random access. The
|
||
basic idea of iterators is simple. A new built-in function, <code class="docutils literal notranslate"><span class="pre">iter(obj)</span></code>
|
||
or <code class="docutils literal notranslate"><span class="pre">iter(C,</span> <span class="pre">sentinel)</span></code>, is used to get an iterator. <code class="docutils literal notranslate"><span class="pre">iter(obj)</span></code> returns
|
||
an iterator for the object <em>obj</em>, while <code class="docutils literal notranslate"><span class="pre">iter(C,</span> <span class="pre">sentinel)</span></code> returns an
|
||
iterator that will invoke the callable object <em>C</em> until it returns <em>sentinel</em> to
|
||
signal that the iterator is done.</p>
|
||
<p>Python classes can define an <a class="reference internal" href="../reference/datamodel.html#object.__iter__" title="object.__iter__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__iter__()</span></code></a> method, which should create and
|
||
return a new iterator for the object; if the object is its own iterator, this
|
||
method can just return <code class="docutils literal notranslate"><span class="pre">self</span></code>. In particular, iterators will usually be their
|
||
own iterators. Extension types implemented in C can implement a <a class="reference internal" href="../c-api/typeobj.html#c.PyTypeObject.tp_iter" title="PyTypeObject.tp_iter"><code class="xref c c-member docutils literal notranslate"><span class="pre">tp_iter</span></code></a>
|
||
function in order to return an iterator, and extension types that want to behave
|
||
as iterators can define a <a class="reference internal" href="../c-api/typeobj.html#c.PyTypeObject.tp_iternext" title="PyTypeObject.tp_iternext"><code class="xref c c-member docutils literal notranslate"><span class="pre">tp_iternext</span></code></a> function.</p>
|
||
<p>So, after all this, what do iterators actually do? They have one required
|
||
method, <a class="reference internal" href="../library/functions.html#next" title="next"><code class="xref py py-meth docutils literal notranslate"><span class="pre">next()</span></code></a>, which takes no arguments and returns the next value. When
|
||
there are no more values to be returned, calling <a class="reference internal" href="../library/functions.html#next" title="next"><code class="xref py py-meth docutils literal notranslate"><span class="pre">next()</span></code></a> should raise the
|
||
<a class="reference internal" href="../library/exceptions.html#StopIteration" title="StopIteration"><code class="xref py py-exc docutils literal notranslate"><span class="pre">StopIteration</span></code></a> exception.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">L</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="gp">>>> </span><span class="n">i</span> <span class="o">=</span> <span class="nb">iter</span><span class="p">(</span><span class="n">L</span><span class="p">)</span>
|
||
<span class="gp">>>> </span><span class="nb">print</span> <span class="n">i</span>
|
||
<span class="go"><iterator object at 0x8116870></span>
|
||
<span class="gp">>>> </span><span class="n">i</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">1</span>
|
||
<span class="gp">>>> </span><span class="n">i</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">2</span>
|
||
<span class="gp">>>> </span><span class="n">i</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">3</span>
|
||
<span class="gp">>>> </span><span class="n">i</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="gt">Traceback (most recent call last):</span>
|
||
File <span class="nb">"<stdin>"</span>, line <span class="m">1</span>, in <span class="n">?</span>
|
||
<span class="gr">StopIteration</span>
|
||
<span class="go">>>></span>
|
||
</pre></div>
|
||
</div>
|
||
<p>In 2.2, Python’s <a class="reference internal" href="../reference/compound_stmts.html#for"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">for</span></code></a> statement no longer expects a sequence; it
|
||
expects something for which <a class="reference internal" href="../library/functions.html#iter" title="iter"><code class="xref py py-func docutils literal notranslate"><span class="pre">iter()</span></code></a> will return an iterator. For backward
|
||
compatibility and convenience, an iterator is automatically constructed for
|
||
sequences that don’t implement <a class="reference internal" href="../reference/datamodel.html#object.__iter__" title="object.__iter__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__iter__()</span></code></a> or a <a class="reference internal" href="../c-api/typeobj.html#c.PyTypeObject.tp_iter" title="PyTypeObject.tp_iter"><code class="xref c c-member docutils literal notranslate"><span class="pre">tp_iter</span></code></a> slot, so
|
||
<code class="docutils literal notranslate"><span class="pre">for</span> <span class="pre">i</span> <span class="pre">in</span> <span class="pre">[1,2,3]</span></code> will still work. Wherever the Python interpreter loops
|
||
over a sequence, it’s been changed to use the iterator protocol. This means you
|
||
can do things like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">L</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="gp">>>> </span><span class="n">i</span> <span class="o">=</span> <span class="nb">iter</span><span class="p">(</span><span class="n">L</span><span class="p">)</span>
|
||
<span class="gp">>>> </span><span class="n">a</span><span class="p">,</span><span class="n">b</span><span class="p">,</span><span class="n">c</span> <span class="o">=</span> <span class="n">i</span>
|
||
<span class="gp">>>> </span><span class="n">a</span><span class="p">,</span><span class="n">b</span><span class="p">,</span><span class="n">c</span>
|
||
<span class="go">(1, 2, 3)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Iterator support has been added to some of Python’s basic types. Calling
|
||
<a class="reference internal" href="../library/functions.html#iter" title="iter"><code class="xref py py-func docutils literal notranslate"><span class="pre">iter()</span></code></a> on a dictionary will return an iterator which loops over its keys:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">m</span> <span class="o">=</span> <span class="p">{</span><span class="s1">'Jan'</span><span class="p">:</span> <span class="mi">1</span><span class="p">,</span> <span class="s1">'Feb'</span><span class="p">:</span> <span class="mi">2</span><span class="p">,</span> <span class="s1">'Mar'</span><span class="p">:</span> <span class="mi">3</span><span class="p">,</span> <span class="s1">'Apr'</span><span class="p">:</span> <span class="mi">4</span><span class="p">,</span> <span class="s1">'May'</span><span class="p">:</span> <span class="mi">5</span><span class="p">,</span> <span class="s1">'Jun'</span><span class="p">:</span> <span class="mi">6</span><span class="p">,</span>
|
||
<span class="gp">... </span> <span class="s1">'Jul'</span><span class="p">:</span> <span class="mi">7</span><span class="p">,</span> <span class="s1">'Aug'</span><span class="p">:</span> <span class="mi">8</span><span class="p">,</span> <span class="s1">'Sep'</span><span class="p">:</span> <span class="mi">9</span><span class="p">,</span> <span class="s1">'Oct'</span><span class="p">:</span> <span class="mi">10</span><span class="p">,</span> <span class="s1">'Nov'</span><span class="p">:</span> <span class="mi">11</span><span class="p">,</span> <span class="s1">'Dec'</span><span class="p">:</span> <span class="mi">12</span><span class="p">}</span>
|
||
<span class="gp">>>> </span><span class="k">for</span> <span class="n">key</span> <span class="ow">in</span> <span class="n">m</span><span class="p">:</span> <span class="nb">print</span> <span class="n">key</span><span class="p">,</span> <span class="n">m</span><span class="p">[</span><span class="n">key</span><span class="p">]</span>
|
||
<span class="gp">...</span>
|
||
<span class="go">Mar 3</span>
|
||
<span class="go">Feb 2</span>
|
||
<span class="go">Aug 8</span>
|
||
<span class="go">Sep 9</span>
|
||
<span class="go">May 5</span>
|
||
<span class="go">Jun 6</span>
|
||
<span class="go">Jul 7</span>
|
||
<span class="go">Jan 1</span>
|
||
<span class="go">Apr 4</span>
|
||
<span class="go">Nov 11</span>
|
||
<span class="go">Dec 12</span>
|
||
<span class="go">Oct 10</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>That’s just the default behaviour. If you want to iterate over keys, values, or
|
||
key/value pairs, you can explicitly call the <code class="xref py py-meth docutils literal notranslate"><span class="pre">iterkeys()</span></code>,
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">itervalues()</span></code>, or <code class="xref py py-meth docutils literal notranslate"><span class="pre">iteritems()</span></code> methods to get an appropriate iterator.
|
||
In a minor related change, the <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 now works on dictionaries,
|
||
so <code class="docutils literal notranslate"><span class="pre">key</span> <span class="pre">in</span> <span class="pre">dict</span></code> is now equivalent to <code class="docutils literal notranslate"><span class="pre">dict.has_key(key)</span></code>.</p>
|
||
<p>Files also provide an iterator, which calls the <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> method until
|
||
there are no more lines in the file. This means you can now read each line of a
|
||
file using code like this:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">for</span> <span class="n">line</span> <span class="ow">in</span> <span class="n">file</span><span class="p">:</span>
|
||
<span class="c1"># do something for each line</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Note that you can only go forward in an iterator; there’s no way to get the
|
||
previous element, reset the iterator, or make a copy of it. An iterator object
|
||
could provide such additional capabilities, but the iterator protocol only
|
||
requires a <a class="reference internal" href="../library/functions.html#next" title="next"><code class="xref py py-meth docutils literal notranslate"><span class="pre">next()</span></code></a> method.</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-7"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0234"><strong>PEP 234</strong></a> - Iterators</dt><dd><p>Written by Ka-Ping Yee and GvR; implemented by the Python Labs crew, mostly by
|
||
GvR and Tim Peters.</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="pep-255-simple-generators">
|
||
<h2>PEP 255: Simple Generators<a class="headerlink" href="#pep-255-simple-generators" title="Permalink to this headline">¶</a></h2>
|
||
<p>Generators are another new feature, one that interacts with the introduction of
|
||
iterators.</p>
|
||
<p>You’re doubtless familiar with how function calls work in Python or C. When you
|
||
call a function, it gets a private namespace where its local variables are
|
||
created. When the function reaches a <a class="reference internal" href="../reference/simple_stmts.html#return"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">return</span></code></a> statement, the local
|
||
variables are destroyed and the resulting value is returned to the caller. A
|
||
later call to the same function will get a fresh new set of local variables.
|
||
But, what if the local variables weren’t thrown away on exiting a function?
|
||
What if you could later resume the function where it left off? This is what
|
||
generators provide; they can be thought of as resumable functions.</p>
|
||
<p>Here’s the simplest example of a generator function:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">generate_ints</span><span class="p">(</span><span class="n">N</span><span class="p">):</span>
|
||
<span class="k">for</span> <span class="n">i</span> <span class="ow">in</span> <span class="nb">range</span><span class="p">(</span><span class="n">N</span><span class="p">):</span>
|
||
<span class="k">yield</span> <span class="n">i</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>A new keyword, <a class="reference internal" href="../reference/simple_stmts.html#yield"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code></a>, was introduced for generators. Any function
|
||
containing a <code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code> statement is a generator function; this is
|
||
detected by Python’s bytecode compiler which compiles the function specially as
|
||
a result. Because a new keyword was introduced, generators must be explicitly
|
||
enabled in a module by including a <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">__future__</span> <span class="pre">import</span> <span class="pre">generators</span></code>
|
||
statement near the top of the module’s source code. In Python 2.3 this
|
||
statement will become unnecessary.</p>
|
||
<p>When you call a generator function, it doesn’t return a single value; instead it
|
||
returns a generator object that supports the iterator protocol. On executing
|
||
the <a class="reference internal" href="../reference/simple_stmts.html#yield"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code></a> statement, the generator outputs the value of <code class="docutils literal notranslate"><span class="pre">i</span></code>,
|
||
similar to a <a class="reference internal" href="../reference/simple_stmts.html#return"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">return</span></code></a> statement. The big difference between
|
||
<code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code> and a <code class="xref std std-keyword docutils literal notranslate"><span class="pre">return</span></code> statement is that on reaching a
|
||
<code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code> the generator’s state of execution is suspended and local
|
||
variables are preserved. On the next call to the generator’s <code class="docutils literal notranslate"><span class="pre">next()</span></code> method,
|
||
the function will resume executing immediately after the <code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code>
|
||
statement. (For complicated reasons, the <code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code> statement isn’t
|
||
allowed inside the <code class="xref std std-keyword docutils literal notranslate"><span class="pre">try</span></code> block of a
|
||
<a class="reference internal" href="../reference/compound_stmts.html#try"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">try</span></code></a>…<a class="reference internal" href="../reference/compound_stmts.html#finally"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">finally</span></code></a> statement; read <span class="target" id="index-8"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0255"><strong>PEP 255</strong></a> for a full
|
||
explanation of the interaction between <code class="xref std std-keyword docutils literal notranslate"><span class="pre">yield</span></code> and exceptions.)</p>
|
||
<p>Here’s a sample usage of the <code class="xref py py-func docutils literal notranslate"><span class="pre">generate_ints()</span></code> generator:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">gen</span> <span class="o">=</span> <span class="n">generate_ints</span><span class="p">(</span><span class="mi">3</span><span class="p">)</span>
|
||
<span class="gp">>>> </span><span class="n">gen</span>
|
||
<span class="go"><generator object at 0x8117f90></span>
|
||
<span class="gp">>>> </span><span class="n">gen</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">0</span>
|
||
<span class="gp">>>> </span><span class="n">gen</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">1</span>
|
||
<span class="gp">>>> </span><span class="n">gen</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="go">2</span>
|
||
<span class="gp">>>> </span><span class="n">gen</span><span class="o">.</span><span class="n">next</span><span class="p">()</span>
|
||
<span class="gt">Traceback (most recent call last):</span>
|
||
File <span class="nb">"<stdin>"</span>, line <span class="m">1</span>, in <span class="n">?</span>
|
||
File <span class="nb">"<stdin>"</span>, line <span class="m">2</span>, in <span class="n">generate_ints</span>
|
||
<span class="gr">StopIteration</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>You could equally write <code class="docutils literal notranslate"><span class="pre">for</span> <span class="pre">i</span> <span class="pre">in</span> <span class="pre">generate_ints(5)</span></code>, or <code class="docutils literal notranslate"><span class="pre">a,b,c</span> <span class="pre">=</span>
|
||
<span class="pre">generate_ints(3)</span></code>.</p>
|
||
<p>Inside a generator function, the <a class="reference internal" href="../reference/simple_stmts.html#return"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">return</span></code></a> statement can only be used
|
||
without a value, and signals the end of the procession of values; afterwards the
|
||
generator cannot return any further values. <code class="xref std std-keyword docutils literal notranslate"><span class="pre">return</span></code> with a value, such
|
||
as <code class="docutils literal notranslate"><span class="pre">return</span> <span class="pre">5</span></code>, is a syntax error inside a generator function. The end of the
|
||
generator’s results can also be indicated by raising <a class="reference internal" href="../library/exceptions.html#StopIteration" title="StopIteration"><code class="xref py py-exc docutils literal notranslate"><span class="pre">StopIteration</span></code></a>
|
||
manually, or by just letting the flow of execution fall off the bottom of the
|
||
function.</p>
|
||
<p>You could achieve the effect of generators manually by writing your own class
|
||
and storing all the local variables of the generator as instance variables. For
|
||
example, returning a list of integers could be done by setting <code class="docutils literal notranslate"><span class="pre">self.count</span></code> to
|
||
0, and having the <a class="reference internal" href="../library/functions.html#next" title="next"><code class="xref py py-meth docutils literal notranslate"><span class="pre">next()</span></code></a> method increment <code class="docutils literal notranslate"><span class="pre">self.count</span></code> and return it.
|
||
However, for a moderately complicated generator, writing a corresponding class
|
||
would be much messier. <code class="file docutils literal notranslate"><span class="pre">Lib/test/test_generators.py</span></code> contains a number of
|
||
more interesting examples. The simplest one implements an in-order traversal of
|
||
a tree using generators recursively.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="c1"># A recursive generator that generates Tree leaves in in-order.</span>
|
||
<span class="k">def</span> <span class="nf">inorder</span><span class="p">(</span><span class="n">t</span><span class="p">):</span>
|
||
<span class="k">if</span> <span class="n">t</span><span class="p">:</span>
|
||
<span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="n">inorder</span><span class="p">(</span><span class="n">t</span><span class="o">.</span><span class="n">left</span><span class="p">):</span>
|
||
<span class="k">yield</span> <span class="n">x</span>
|
||
<span class="k">yield</span> <span class="n">t</span><span class="o">.</span><span class="n">label</span>
|
||
<span class="k">for</span> <span class="n">x</span> <span class="ow">in</span> <span class="n">inorder</span><span class="p">(</span><span class="n">t</span><span class="o">.</span><span class="n">right</span><span class="p">):</span>
|
||
<span class="k">yield</span> <span class="n">x</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Two other examples in <code class="file docutils literal notranslate"><span class="pre">Lib/test/test_generators.py</span></code> produce solutions for
|
||
the N-Queens problem (placing $N$ queens on an $NxN$ chess board so that no
|
||
queen threatens another) and the Knight’s Tour (a route that takes a knight to
|
||
every square of an $NxN$ chessboard without visiting any square twice).</p>
|
||
<p>The idea of generators comes from other programming languages, especially Icon
|
||
(<a class="reference external" href="https://www.cs.arizona.edu/icon/">https://www.cs.arizona.edu/icon/</a>), where the idea of generators is central. In
|
||
Icon, every expression and function call behaves like a generator. One example
|
||
from “An Overview of the Icon Programming Language” at
|
||
<a class="reference external" href="https://www.cs.arizona.edu/icon/docs/ipd266.htm">https://www.cs.arizona.edu/icon/docs/ipd266.htm</a> gives an idea of what this looks
|
||
like:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">sentence</span> <span class="p">:</span><span class="o">=</span> <span class="s2">"Store it in the neighboring harbor"</span>
|
||
<span class="k">if</span> <span class="p">(</span><span class="n">i</span> <span class="p">:</span><span class="o">=</span> <span class="n">find</span><span class="p">(</span><span class="s2">"or"</span><span class="p">,</span> <span class="n">sentence</span><span class="p">))</span> <span class="o">></span> <span class="mi">5</span> <span class="n">then</span> <span class="n">write</span><span class="p">(</span><span class="n">i</span><span class="p">)</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>In Icon the <code class="xref py py-func docutils literal notranslate"><span class="pre">find()</span></code> function returns the indexes at which the substring
|
||
“or” is found: 3, 23, 33. In the <a class="reference internal" href="../reference/compound_stmts.html#if"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">if</span></code></a> statement, <code class="docutils literal notranslate"><span class="pre">i</span></code> is first
|
||
assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon
|
||
retries it with the second value of 23. 23 is greater than 5, so the comparison
|
||
now succeeds, and the code prints the value 23 to the screen.</p>
|
||
<p>Python doesn’t go nearly as far as Icon in adopting generators as a central
|
||
concept. Generators are considered a new part of the core Python language, but
|
||
learning or using them isn’t compulsory; if they don’t solve any problems that
|
||
you have, feel free to ignore them. One novel feature of Python’s interface as
|
||
compared to Icon’s is that a generator’s state is represented as a concrete
|
||
object (the iterator) that can be passed around to other functions or stored in
|
||
a data structure.</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-9"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0255"><strong>PEP 255</strong></a> - Simple Generators</dt><dd><p>Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland. Implemented mostly
|
||
by Neil Schemenauer and Tim Peters, with other fixes from the Python Labs crew.</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="pep-237-unifying-long-integers-and-integers">
|
||
<h2>PEP 237: Unifying Long Integers and Integers<a class="headerlink" href="#pep-237-unifying-long-integers-and-integers" title="Permalink to this headline">¶</a></h2>
|
||
<p>In recent versions, the distinction between regular integers, which are 32-bit
|
||
values on most machines, and long integers, which can be of arbitrary size, was
|
||
becoming an annoyance. For example, on platforms that support files larger than
|
||
<code class="docutils literal notranslate"><span class="pre">2**32</span></code> bytes, the <code class="xref py py-meth docutils literal notranslate"><span class="pre">tell()</span></code> method of file objects has to return a long
|
||
integer. However, there were various bits of Python that expected plain integers
|
||
and would raise an error if a long integer was provided instead. For example,
|
||
in Python 1.5, only regular integers could be used as a slice index, and
|
||
<code class="docutils literal notranslate"><span class="pre">'abc'[1L:]</span></code> would raise 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 ‘slice
|
||
index must be int’.</p>
|
||
<p>Python 2.2 will shift values from short to long integers as required. The ‘L’
|
||
suffix is no longer needed to indicate a long integer literal, as now the
|
||
compiler will choose the appropriate type. (Using the ‘L’ suffix will be
|
||
discouraged in future 2.x versions of Python, triggering a warning in Python
|
||
2.4, and probably dropped in Python 3.0.) Many operations that used to raise an
|
||
<a class="reference internal" href="../library/exceptions.html#OverflowError" title="OverflowError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">OverflowError</span></code></a> will now return a long integer as their result. For
|
||
example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="mi">1234567890123</span>
|
||
<span class="go">1234567890123L</span>
|
||
<span class="gp">>>> </span><span class="mi">2</span> <span class="o">**</span> <span class="mi">64</span>
|
||
<span class="go">18446744073709551616L</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>In most cases, integers and long integers will now be treated identically. You
|
||
can still distinguish them with the <a class="reference internal" href="../library/functions.html#type" title="type"><code class="xref py py-func docutils literal notranslate"><span class="pre">type()</span></code></a> built-in function, but that’s
|
||
rarely needed.</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-10"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0237"><strong>PEP 237</strong></a> - Unifying Long Integers and Integers</dt><dd><p>Written by Moshe Zadka and Guido van Rossum. Implemented mostly by Guido van
|
||
Rossum.</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="pep-238-changing-the-division-operator">
|
||
<h2>PEP 238: Changing the Division Operator<a class="headerlink" href="#pep-238-changing-the-division-operator" title="Permalink to this headline">¶</a></h2>
|
||
<p>The most controversial change in Python 2.2 heralds the start of an effort to
|
||
fix an old design flaw that’s been in Python from the beginning. Currently
|
||
Python’s division operator, <code class="docutils literal notranslate"><span class="pre">/</span></code>, behaves like C’s division operator when
|
||
presented with two integer arguments: it returns an integer result that’s
|
||
truncated down when there would be a fractional part. For example, <code class="docutils literal notranslate"><span class="pre">3/2</span></code> is
|
||
1, not 1.5, and <code class="docutils literal notranslate"><span class="pre">(-1)/2</span></code> is -1, not -0.5. This means that the results of
|
||
division can vary unexpectedly depending on the type of the two operands and
|
||
because Python is dynamically typed, it can be difficult to determine the
|
||
possible types of the operands.</p>
|
||
<p>(The controversy is over whether this is <em>really</em> a design flaw, and whether
|
||
it’s worth breaking existing code to fix this. It’s caused endless discussions
|
||
on python-dev, and in July 2001 erupted into a storm of acidly sarcastic
|
||
postings on <em class="newsgroup">comp.lang.python</em>. I won’t argue for either side here
|
||
and will stick to describing what’s implemented in 2.2. Read <span class="target" id="index-11"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0238"><strong>PEP 238</strong></a> for a
|
||
summary of arguments and counter-arguments.)</p>
|
||
<p>Because this change might break code, it’s being introduced very gradually.
|
||
Python 2.2 begins the transition, but the switch won’t be complete until Python
|
||
3.0.</p>
|
||
<p>First, I’ll borrow some terminology from <span class="target" id="index-12"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0238"><strong>PEP 238</strong></a>. “True division” is the
|
||
division that most non-programmers are familiar with: 3/2 is 1.5, 1/4 is 0.25,
|
||
and so forth. “Floor division” is what Python’s <code class="docutils literal notranslate"><span class="pre">/</span></code> operator currently does
|
||
when given integer operands; the result is the floor of the value returned by
|
||
true division. “Classic division” is the current mixed behaviour of <code class="docutils literal notranslate"><span class="pre">/</span></code>; it
|
||
returns the result of floor division when the operands are integers, and returns
|
||
the result of true division when one of the operands is a floating-point number.</p>
|
||
<p>Here are the changes 2.2 introduces:</p>
|
||
<ul>
|
||
<li><p>A new operator, <code class="docutils literal notranslate"><span class="pre">//</span></code>, is the floor division operator. (Yes, we know it looks
|
||
like C++’s comment symbol.) <code class="docutils literal notranslate"><span class="pre">//</span></code> <em>always</em> performs floor division no matter
|
||
what the types of its operands are, so <code class="docutils literal notranslate"><span class="pre">1</span> <span class="pre">//</span> <span class="pre">2</span></code> is 0 and <code class="docutils literal notranslate"><span class="pre">1.0</span> <span class="pre">//</span> <span class="pre">2.0</span></code> is
|
||
also 0.0.</p>
|
||
<p><code class="docutils literal notranslate"><span class="pre">//</span></code> is always available in Python 2.2; you don’t need to enable it using a
|
||
<code class="docutils literal notranslate"><span class="pre">__future__</span></code> statement.</p>
|
||
</li>
|
||
<li><p>By including a <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">__future__</span> <span class="pre">import</span> <span class="pre">division</span></code> in a module, the <code class="docutils literal notranslate"><span class="pre">/</span></code>
|
||
operator will be changed to return the result of true division, so <code class="docutils literal notranslate"><span class="pre">1/2</span></code> is
|
||
0.5. Without the <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statement, <code class="docutils literal notranslate"><span class="pre">/</span></code> still means classic division.
|
||
The default meaning of <code class="docutils literal notranslate"><span class="pre">/</span></code> will not change until Python 3.0.</p></li>
|
||
<li><p>Classes can define methods called <a class="reference internal" href="../reference/datamodel.html#object.__truediv__" title="object.__truediv__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__truediv__()</span></code></a> and <a class="reference internal" href="../reference/datamodel.html#object.__floordiv__" title="object.__floordiv__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__floordiv__()</span></code></a>
|
||
to overload the two division operators. At the C level, there are also slots in
|
||
the <a class="reference internal" href="../c-api/typeobj.html#c.PyNumberMethods" title="PyNumberMethods"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyNumberMethods</span></code></a> structure so extension types can define the two
|
||
operators.</p></li>
|
||
<li><p>Python 2.2 supports some command-line arguments for testing whether code will
|
||
work with the changed division semantics. Running python with <code class="xref std std-option docutils literal notranslate"><span class="pre">-Q</span>
|
||
<span class="pre">warn</span></code> will cause a warning to be issued whenever division is applied to two
|
||
integers. You can use this to find code that’s affected by the change and fix
|
||
it. By default, Python 2.2 will simply perform classic division without a
|
||
warning; the warning will be turned on by default in Python 2.3.</p></li>
|
||
</ul>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-13"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0238"><strong>PEP 238</strong></a> - Changing the Division Operator</dt><dd><p>Written by Moshe Zadka and Guido van Rossum. Implemented by Guido van Rossum..</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="unicode-changes">
|
||
<h2>Unicode Changes<a class="headerlink" href="#unicode-changes" title="Permalink to this headline">¶</a></h2>
|
||
<p>Python’s Unicode support has been enhanced a bit in 2.2. Unicode strings are
|
||
usually stored as UCS-2, as 16-bit unsigned integers. Python 2.2 can also be
|
||
compiled to use UCS-4, 32-bit unsigned integers, as its internal encoding by
|
||
supplying <code class="xref std std-option docutils literal notranslate"><span class="pre">--enable-unicode=ucs4</span></code> to the configure script. (It’s also
|
||
possible to specify <code class="xref std std-option docutils literal notranslate"><span class="pre">--disable-unicode</span></code> to completely disable Unicode
|
||
support.)</p>
|
||
<p>When built to use UCS-4 (a “wide Python”), the interpreter can natively handle
|
||
Unicode characters from U+000000 to U+110000, so the range of legal values for
|
||
the <code class="xref py py-func docutils literal notranslate"><span class="pre">unichr()</span></code> function is expanded accordingly. Using an interpreter
|
||
compiled to use UCS-2 (a “narrow Python”), values greater than 65535 will still
|
||
cause <code class="xref py py-func docutils literal notranslate"><span class="pre">unichr()</span></code> to raise a <a class="reference internal" href="../library/exceptions.html#ValueError" title="ValueError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">ValueError</span></code></a> exception. This is all
|
||
described in <span class="target" id="index-14"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0261"><strong>PEP 261</strong></a>, “Support for ‘wide’ Unicode characters”; consult it for
|
||
further details.</p>
|
||
<p>Another change is simpler to explain. Since their introduction, Unicode strings
|
||
have supported an <code class="xref py py-meth docutils literal notranslate"><span class="pre">encode()</span></code> method to convert the string to a selected
|
||
encoding such as UTF-8 or Latin-1. A symmetric <code class="docutils literal notranslate"><span class="pre">decode([*encoding*])</span></code>
|
||
method has been added to 8-bit strings (though not to Unicode strings) in 2.2.
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">decode()</span></code> assumes that the string is in the specified encoding and decodes
|
||
it, returning whatever is returned by the codec.</p>
|
||
<p>Using this new feature, codecs have been added for tasks not directly related to
|
||
Unicode. For example, codecs have been added for uu-encoding, MIME’s base64
|
||
encoding, and compression with the <a class="reference internal" href="../library/zlib.html#module-zlib" title="zlib: Low-level interface to compression and decompression routines compatible with gzip."><code class="xref py py-mod docutils literal notranslate"><span class="pre">zlib</span></code></a> module:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="gp">>>> </span><span class="n">s</span> <span class="o">=</span> <span class="s2">"""Here is a lengthy piece of redundant, overly verbose,</span>
|
||
<span class="gp">... </span><span class="s2">and repetitive text.</span>
|
||
<span class="gp">... </span><span class="s2">"""</span>
|
||
<span class="gp">>>> </span><span class="n">data</span> <span class="o">=</span> <span class="n">s</span><span class="o">.</span><span class="n">encode</span><span class="p">(</span><span class="s1">'zlib'</span><span class="p">)</span>
|
||
<span class="gp">>>> </span><span class="n">data</span>
|
||
<span class="go">'x\x9c\r\xc9\xc1\r\x80 \x10\x04\xc0?Ul...'</span>
|
||
<span class="gp">>>> </span><span class="n">data</span><span class="o">.</span><span class="n">decode</span><span class="p">(</span><span class="s1">'zlib'</span><span class="p">)</span>
|
||
<span class="go">'Here is a lengthy piece of redundant, overly verbose,\nand repetitive text.\n'</span>
|
||
<span class="gp">>>> </span><span class="nb">print</span> <span class="n">s</span><span class="o">.</span><span class="n">encode</span><span class="p">(</span><span class="s1">'uu'</span><span class="p">)</span>
|
||
<span class="go">begin 666 <data></span>
|
||
<span class="go">M2&5R92!I<R!A(&QE;F=T:'D@<&EE8V4@;V8@<F5D=6YD86YT+"!O=F5R;'D@</span>
|
||
<span class="go">>=F5R8F]S92P*86YD(')E<&5T:71I=F4@=&5X="X*</span>
|
||
|
||
<span class="go">end</span>
|
||
<span class="gp">>>> </span><span class="s2">"sheesh"</span><span class="o">.</span><span class="n">encode</span><span class="p">(</span><span class="s1">'rot-13'</span><span class="p">)</span>
|
||
<span class="go">'furrfu'</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>To convert a class instance to Unicode, a <code class="xref py py-meth docutils literal notranslate"><span class="pre">__unicode__()</span></code> method can be
|
||
defined by a class, analogous to <a class="reference internal" href="../reference/datamodel.html#object.__str__" title="object.__str__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__str__()</span></code></a>.</p>
|
||
<p><code class="xref py py-meth docutils literal notranslate"><span class="pre">encode()</span></code>, <code class="xref py py-meth docutils literal notranslate"><span class="pre">decode()</span></code>, and <code class="xref py py-meth docutils literal notranslate"><span class="pre">__unicode__()</span></code> were implemented by
|
||
Marc-André Lemburg. The changes to support using UCS-4 internally were
|
||
implemented by Fredrik Lundh and Martin von Löwis.</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-15"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0261"><strong>PEP 261</strong></a> - Support for ‘wide’ Unicode characters</dt><dd><p>Written by Paul Prescod.</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="pep-227-nested-scopes">
|
||
<h2>PEP 227: Nested Scopes<a class="headerlink" href="#pep-227-nested-scopes" title="Permalink to this headline">¶</a></h2>
|
||
<p>In Python 2.1, statically nested scopes were added as an optional feature, to be
|
||
enabled by a <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">__future__</span> <span class="pre">import</span> <span class="pre">nested_scopes</span></code> directive. In 2.2 nested
|
||
scopes no longer need to be specially enabled, and are now always present. The
|
||
rest of this section is a copy of the description of nested scopes from my
|
||
“What’s New in Python 2.1” document; if you read it when 2.1 came out, you can
|
||
skip the rest of this section.</p>
|
||
<p>The largest change introduced in Python 2.1, and made complete in 2.2, is to
|
||
Python’s scoping rules. In Python 2.0, at any given time there are at most
|
||
three namespaces used to look up variable names: local, module-level, and the
|
||
built-in namespace. This often surprised people because it didn’t match their
|
||
intuitive expectations. For example, a nested recursive function definition
|
||
doesn’t 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="o">...</span>
|
||
<span class="k">def</span> <span class="nf">g</span><span class="p">(</span><span class="n">value</span><span class="p">):</span>
|
||
<span class="o">...</span>
|
||
<span class="k">return</span> <span class="n">g</span><span class="p">(</span><span class="n">value</span><span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="o">+</span> <span class="mi">1</span>
|
||
<span class="o">...</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The function <code class="xref py py-func docutils literal notranslate"><span class="pre">g()</span></code> will always raise 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, because
|
||
the binding of the name <code class="docutils literal notranslate"><span class="pre">g</span></code> isn’t in either its local namespace or in the
|
||
module-level namespace. This isn’t much of a problem in practice (how often do
|
||
you recursively define interior functions like this?), but this also made using
|
||
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 clumsier, and this was a problem in practice.
|
||
In code which uses <code class="xref std std-keyword docutils literal notranslate"><span class="pre">lambda</span></code> you can often find local variables being
|
||
copied by passing them as the default values of arguments.</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="k">def</span> <span class="nf">find</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="s2">"Return list of any entries equal to 'name'"</span>
|
||
<span class="n">L</span> <span class="o">=</span> <span class="nb">filter</span><span class="p">(</span><span class="k">lambda</span> <span class="n">x</span><span class="p">,</span> <span class="n">name</span><span class="o">=</span><span class="n">name</span><span class="p">:</span> <span class="n">x</span> <span class="o">==</span> <span class="n">name</span><span class="p">,</span>
|
||
<span class="bp">self</span><span class="o">.</span><span class="n">list_attribute</span><span class="p">)</span>
|
||
<span class="k">return</span> <span class="n">L</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The readability of Python code written in a strongly functional style suffers
|
||
greatly as a result.</p>
|
||
<p>The most significant change to Python 2.2 is that static scoping has been added
|
||
to the language to fix this problem. As a first effect, the <code class="docutils literal notranslate"><span class="pre">name=name</span></code>
|
||
default argument is now unnecessary in the above example. Put simply, when a
|
||
given variable name is not assigned a value within a function (by an assignment,
|
||
or the <a class="reference internal" href="../reference/compound_stmts.html#def"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">def</span></code></a>, <a class="reference internal" href="../reference/compound_stmts.html#class"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">class</span></code></a>, or <a class="reference internal" href="../reference/simple_stmts.html#import"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">import</span></code></a> statements),
|
||
references to the variable will be looked up in the local namespace of the
|
||
enclosing scope. A more detailed explanation of the rules, and a dissection of
|
||
the implementation, can be found in the PEP.</p>
|
||
<p>This change may cause some compatibility problems for code where the same
|
||
variable name is used both at the module level and as a local variable within a
|
||
function that contains further function definitions. This seems rather unlikely
|
||
though, since such code would have been pretty confusing to read in the first
|
||
place.</p>
|
||
<p>One side effect of the change is that the <code class="docutils literal notranslate"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> and
|
||
<code class="docutils literal notranslate"><span class="pre">exec</span></code> statements have been made illegal inside a function scope under
|
||
certain conditions. The Python reference manual has said all along that <code class="docutils literal notranslate"><span class="pre">from</span>
|
||
<span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> is only legal at the top level of a module, but the CPython
|
||
interpreter has never enforced this before. As part of the implementation of
|
||
nested scopes, the compiler which turns Python source into bytecodes has to
|
||
generate different code to access variables in a containing scope. <code class="docutils literal notranslate"><span class="pre">from</span>
|
||
<span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></code> and <code class="docutils literal notranslate"><span class="pre">exec</span></code> make it impossible for the compiler to
|
||
figure this out, because they add names to the local namespace that are
|
||
unknowable at compile time. Therefore, if a function contains function
|
||
definitions or <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> expressions with free variables, the compiler
|
||
will flag this by raising a <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> exception.</p>
|
||
<p>To make the preceding explanation a bit clearer, here’s an example:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="n">x</span> <span class="o">=</span> <span class="mi">1</span>
|
||
<span class="k">def</span> <span class="nf">f</span><span class="p">():</span>
|
||
<span class="c1"># The next line is a syntax error</span>
|
||
<span class="n">exec</span> <span class="s1">'x=2'</span>
|
||
<span class="k">def</span> <span class="nf">g</span><span class="p">():</span>
|
||
<span class="k">return</span> <span class="n">x</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>Line 4 containing the <code class="docutils literal notranslate"><span class="pre">exec</span></code> statement is a syntax error, since
|
||
<code class="docutils literal notranslate"><span class="pre">exec</span></code> would define a new local variable named <code class="docutils literal notranslate"><span class="pre">x</span></code> whose value should
|
||
be accessed by <code class="xref py py-func docutils literal notranslate"><span class="pre">g()</span></code>.</p>
|
||
<p>This shouldn’t be much of a limitation, since <code class="docutils literal notranslate"><span class="pre">exec</span></code> is rarely used in
|
||
most Python code (and when it is used, it’s often a sign of a poor design
|
||
anyway).</p>
|
||
<div class="admonition seealso">
|
||
<p class="admonition-title">See also</p>
|
||
<dl class="simple">
|
||
<dt><span class="target" id="index-16"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0227"><strong>PEP 227</strong></a> - Statically Nested Scopes</dt><dd><p>Written and implemented by Jeremy Hylton.</p>
|
||
</dd>
|
||
</dl>
|
||
</div>
|
||
</div>
|
||
<div class="section" id="new-and-improved-modules">
|
||
<h2>New and Improved Modules<a class="headerlink" href="#new-and-improved-modules" title="Permalink to this headline">¶</a></h2>
|
||
<ul>
|
||
<li><p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">xmlrpclib</span></code> module was contributed to the standard library by Fredrik
|
||
Lundh, providing support for writing XML-RPC clients. XML-RPC is a simple
|
||
remote procedure call protocol built on top of HTTP and XML. For example, the
|
||
following snippet retrieves a list of RSS channels from the O’Reilly Network,
|
||
and then lists the recent headlines for one channel:</p>
|
||
<div class="highlight-python3 notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">xmlrpclib</span>
|
||
<span class="n">s</span> <span class="o">=</span> <span class="n">xmlrpclib</span><span class="o">.</span><span class="n">Server</span><span class="p">(</span>
|
||
<span class="s1">'http://www.oreillynet.com/meerkat/xml-rpc/server.php'</span><span class="p">)</span>
|
||
<span class="n">channels</span> <span class="o">=</span> <span class="n">s</span><span class="o">.</span><span class="n">meerkat</span><span class="o">.</span><span class="n">getChannels</span><span class="p">()</span>
|
||
<span class="c1"># channels is a list of dictionaries, like this:</span>
|
||
<span class="c1"># [{'id': 4, 'title': 'Freshmeat Daily News'}</span>
|
||
<span class="c1"># {'id': 190, 'title': '32Bits Online'},</span>
|
||
<span class="c1"># {'id': 4549, 'title': '3DGamers'}, ... ]</span>
|
||
|
||
<span class="c1"># Get the items for one channel</span>
|
||
<span class="n">items</span> <span class="o">=</span> <span class="n">s</span><span class="o">.</span><span class="n">meerkat</span><span class="o">.</span><span class="n">getItems</span><span class="p">(</span> <span class="p">{</span><span class="s1">'channel'</span><span class="p">:</span> <span class="mi">4</span><span class="p">}</span> <span class="p">)</span>
|
||
|
||
<span class="c1"># 'items' is another list of dictionaries, like this:</span>
|
||
<span class="c1"># [{'link': 'http://freshmeat.net/releases/52719/',</span>
|
||
<span class="c1"># 'description': 'A utility which converts HTML to XSL FO.',</span>
|
||
<span class="c1"># 'title': 'html2fo 0.3 (Default)'}, ... ]</span>
|
||
</pre></div>
|
||
</div>
|
||
<p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">SimpleXMLRPCServer</span></code> module makes it easy to create straightforward
|
||
XML-RPC servers. See <a class="reference external" href="http://xmlrpc.scripting.com/">http://xmlrpc.scripting.com/</a> for more information about XML-RPC.</p>
|
||
</li>
|
||
<li><p>The new <a class="reference internal" href="../library/hmac.html#module-hmac" title="hmac: Keyed-Hashing for Message Authentication (HMAC) implementation"><code class="xref py py-mod docutils literal notranslate"><span class="pre">hmac</span></code></a> module implements the HMAC algorithm described by
|
||
<span class="target" id="index-17"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc2104.html"><strong>RFC 2104</strong></a>. (Contributed by Gerhard Häring.)</p></li>
|
||
<li><p>Several functions that originally returned lengthy tuples now return
|
||
pseudo-sequences that still behave like tuples but also have mnemonic attributes such
|
||
as memberst_mtime or <code class="xref py py-attr docutils literal notranslate"><span class="pre">tm_year</span></code>. The enhanced functions include
|
||
<a class="reference internal" href="../library/stat.html#module-stat" title="stat: Utilities for interpreting the results of os.stat(), os.lstat() and os.fstat()."><code class="xref py py-func docutils literal notranslate"><span class="pre">stat()</span></code></a>, <code class="xref py py-func docutils literal notranslate"><span class="pre">fstat()</span></code>, <code class="xref py py-func docutils literal notranslate"><span class="pre">statvfs()</span></code>, and <code class="xref py py-func docutils literal notranslate"><span class="pre">fstatvfs()</span></code> in the
|
||
<a class="reference internal" href="../library/os.html#module-os" title="os: Miscellaneous operating system interfaces."><code class="xref py py-mod docutils literal notranslate"><span class="pre">os</span></code></a> module, and <code class="xref py py-func docutils literal notranslate"><span class="pre">localtime()</span></code>, <code class="xref py py-func docutils literal notranslate"><span class="pre">gmtime()</span></code>, and <code class="xref py py-func docutils literal notranslate"><span class="pre">strptime()</span></code> in
|
||
the <a class="reference internal" href="../library/time.html#module-time" title="time: Time access and conversions."><code class="xref py py-mod docutils literal notranslate"><span class="pre">time</span></code></a> module.</p>
|
||
<p>For example, to obtain a file’s size using the old tuples, you’d end up writing
|
||
something like <code class="docutils literal notranslate"><span class="pre">file_size</span> <span class="pre">=</span> <span class="pre">os.stat(filename)[stat.ST_SIZE]</span></code>, but now this can
|
||
be written more clearly as <code class="docutils literal notranslate"><span class="pre">file_size</span> <span class="pre">=</span> <span class="pre">os.stat(filename).st_size</span></code>.</p>
|
||
<p>The original patch for this feature was contributed by Nick Mathewson.</p>
|
||
</li>
|
||
<li><p>The Python profiler has been extensively reworked and various errors in its
|
||
output have been corrected. (Contributed by Fred L. Drake, Jr. and Tim Peters.)</p></li>
|
||
<li><p>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 can be compiled to support IPv6; specify the
|
||
<code class="xref std std-option docutils literal notranslate"><span class="pre">--enable-ipv6</span></code> option to Python’s configure script. (Contributed by
|
||
Jun-ichiro “itojun” Hagino.)</p></li>
|
||
<li><p>Two new format characters were added to the <a class="reference internal" href="../library/struct.html#module-struct" title="struct: Interpret bytes as packed binary data."><code class="xref py py-mod docutils literal notranslate"><span class="pre">struct</span></code></a> module for 64-bit
|
||
integers on platforms that support the C <code class="xref c c-type docutils literal notranslate"><span class="pre">long</span> <span class="pre">long</span></code> type. <code class="docutils literal notranslate"><span class="pre">q</span></code> is for
|
||
a signed 64-bit integer, and <code class="docutils literal notranslate"><span class="pre">Q</span></code> is for an unsigned one. The value is
|
||
returned in Python’s long integer type. (Contributed by Tim Peters.)</p></li>
|
||
<li><p>In the interpreter’s interactive mode, there’s a new built-in function
|
||
<a class="reference internal" href="../library/functions.html#help" title="help"><code class="xref py py-func docutils literal notranslate"><span class="pre">help()</span></code></a> that uses the <a class="reference internal" href="../library/pydoc.html#module-pydoc" title="pydoc: Documentation generator and online help system."><code class="xref py py-mod docutils literal notranslate"><span class="pre">pydoc</span></code></a> module introduced in Python 2.1 to
|
||
provide interactive help. <code class="docutils literal notranslate"><span class="pre">help(object)</span></code> displays any available help text
|
||
about <em>object</em>. <a class="reference internal" href="../library/functions.html#help" title="help"><code class="xref py py-func docutils literal notranslate"><span class="pre">help()</span></code></a> with no argument puts you in an online help
|
||
utility, where you can enter the names of functions, classes, or modules to read
|
||
their help text. (Contributed by Guido van Rossum, using Ka-Ping Yee’s
|
||
<a class="reference internal" href="../library/pydoc.html#module-pydoc" title="pydoc: Documentation generator and online help system."><code class="xref py py-mod docutils literal notranslate"><span class="pre">pydoc</span></code></a> module.)</p></li>
|
||
<li><p>Various bugfixes and performance improvements have been made to the SRE engine
|
||
underlying 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. For example, the <a class="reference internal" href="../library/re.html#re.sub" title="re.sub"><code class="xref py py-func docutils literal notranslate"><span class="pre">re.sub()</span></code></a> and
|
||
<a class="reference internal" href="../library/re.html#re.split" title="re.split"><code class="xref py py-func docutils literal notranslate"><span class="pre">re.split()</span></code></a> functions have been rewritten in C. Another contributed patch
|
||
speeds up certain Unicode character ranges by a factor of two, and a new
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">finditer()</span></code> method that returns an iterator over all the non-overlapping
|
||
matches in a given string. (SRE is maintained by Fredrik Lundh. The
|
||
BIGCHARSET patch was contributed by Martin von Löwis.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../library/smtplib.html#module-smtplib" title="smtplib: SMTP protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">smtplib</span></code></a> module now supports <span class="target" id="index-18"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc2487.html"><strong>RFC 2487</strong></a>, “Secure SMTP over TLS”, so
|
||
it’s now possible to encrypt the SMTP traffic between a Python program and the
|
||
mail transport agent being handed a message. <a class="reference internal" href="../library/smtplib.html#module-smtplib" title="smtplib: SMTP protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">smtplib</span></code></a> also supports SMTP
|
||
authentication. (Contributed by Gerhard Häring.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../library/imaplib.html#module-imaplib" title="imaplib: IMAP4 protocol client (requires sockets)."><code class="xref py py-mod docutils literal notranslate"><span class="pre">imaplib</span></code></a> module, maintained by Piers Lauder, has support for several
|
||
new extensions: the NAMESPACE extension defined in <span class="target" id="index-19"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc2342.html"><strong>RFC 2342</strong></a>, SORT, GETACL and
|
||
SETACL. (Contributed by Anthony Baxter and Michel Pelletier.)</p></li>
|
||
<li><p>The <code class="xref py py-mod docutils literal notranslate"><span class="pre">rfc822</span></code> module’s parsing of email addresses is now compliant with
|
||
<span class="target" id="index-20"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc2822.html"><strong>RFC 2822</strong></a>, an update to <span class="target" id="index-21"></span><a class="rfc reference external" href="https://tools.ietf.org/html/rfc822.html"><strong>RFC 822</strong></a>. (The module’s name is <em>not</em> going to be
|
||
changed to <code class="docutils literal notranslate"><span class="pre">rfc2822</span></code>.) A new package, <a class="reference internal" href="../library/email.html#module-email" title="email: Package supporting the parsing, manipulating, and generating email messages."><code class="xref py py-mod docutils literal notranslate"><span class="pre">email</span></code></a>, has also been added for
|
||
parsing and generating e-mail messages. (Contributed by Barry Warsaw, and
|
||
arising out of his work on Mailman.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../library/difflib.html#module-difflib" title="difflib: Helpers for computing differences between objects."><code class="xref py py-mod docutils literal notranslate"><span class="pre">difflib</span></code></a> module now contains a new <code class="xref py py-class docutils literal notranslate"><span class="pre">Differ</span></code> class for
|
||
producing human-readable lists of changes (a “delta”) between two sequences of
|
||
lines of text. There are also two generator functions, <code class="xref py py-func docutils literal notranslate"><span class="pre">ndiff()</span></code> and
|
||
<code class="xref py py-func docutils literal notranslate"><span class="pre">restore()</span></code>, which respectively return a delta from two sequences, or one of
|
||
the original sequences from a delta. (Grunt work contributed by David Goodger,
|
||
from ndiff.py code by Tim Peters who then did the generatorization.)</p></li>
|
||
<li><p>New constants <code class="xref py py-const docutils literal notranslate"><span class="pre">ascii_letters</span></code>, <code class="xref py py-const docutils literal notranslate"><span class="pre">ascii_lowercase</span></code>, and
|
||
<code class="xref py py-const docutils literal notranslate"><span class="pre">ascii_uppercase</span></code> were added to 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. There were
|
||
several modules in the standard library that used <code class="xref py py-const docutils literal notranslate"><span class="pre">string.letters</span></code> to
|
||
mean the ranges A-Za-z, but that assumption is incorrect when locales are in
|
||
use, because <code class="xref py py-const docutils literal notranslate"><span class="pre">string.letters</span></code> varies depending on the set of legal
|
||
characters defined by the current locale. The buggy modules have all been fixed
|
||
to use <code class="xref py py-const docutils literal notranslate"><span class="pre">ascii_letters</span></code> instead. (Reported by an unknown person; fixed by
|
||
Fred L. Drake, Jr.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../library/mimetypes.html#module-mimetypes" title="mimetypes: Mapping of filename extensions to MIME types."><code class="xref py py-mod docutils literal notranslate"><span class="pre">mimetypes</span></code></a> module now makes it easier to use alternative MIME-type
|
||
databases by the addition of a <code class="xref py py-class docutils literal notranslate"><span class="pre">MimeTypes</span></code> class, which takes a list of
|
||
filenames to be parsed. (Contributed by Fred L. Drake, Jr.)</p></li>
|
||
<li><p>A <code class="xref py py-class docutils literal notranslate"><span class="pre">Timer</span></code> class was added to the <a class="reference internal" href="../library/threading.html#module-threading" title="threading: Thread-based parallelism."><code class="xref py py-mod docutils literal notranslate"><span class="pre">threading</span></code></a> module that allows
|
||
scheduling an activity to happen at some future time. (Contributed by Itamar
|
||
Shtull-Trauring.)</p></li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="interpreter-changes-and-fixes">
|
||
<h2>Interpreter Changes and Fixes<a class="headerlink" href="#interpreter-changes-and-fixes" title="Permalink to this headline">¶</a></h2>
|
||
<p>Some of the changes only affect people who deal with the Python interpreter at
|
||
the C level because they’re writing Python extension modules, embedding the
|
||
interpreter, or just hacking on the interpreter itself. If you only write Python
|
||
code, none of the changes described here will affect you very much.</p>
|
||
<ul>
|
||
<li><p>Profiling and tracing functions can now be implemented in C, which can operate
|
||
at much higher speeds than Python-based functions and should reduce the overhead
|
||
of profiling and tracing. This will be of interest to authors of development
|
||
environments for Python. Two new C functions were added to Python’s API,
|
||
<a class="reference internal" href="../c-api/init.html#c.PyEval_SetProfile" title="PyEval_SetProfile"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyEval_SetProfile()</span></code></a> and <a class="reference internal" href="../c-api/init.html#c.PyEval_SetTrace" title="PyEval_SetTrace"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyEval_SetTrace()</span></code></a>. The existing
|
||
<a class="reference internal" href="../library/sys.html#sys.setprofile" title="sys.setprofile"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.setprofile()</span></code></a> and <a class="reference internal" href="../library/sys.html#sys.settrace" title="sys.settrace"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.settrace()</span></code></a> functions still exist, and have
|
||
simply been changed to use the new C-level interface. (Contributed by Fred L.
|
||
Drake, Jr.)</p></li>
|
||
<li><p>Another low-level API, primarily of interest to implementors of Python
|
||
debuggers and development tools, was added. <a class="reference internal" href="../c-api/init.html#c.PyInterpreterState_Head" title="PyInterpreterState_Head"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyInterpreterState_Head()</span></code></a> and
|
||
<a class="reference internal" href="../c-api/init.html#c.PyInterpreterState_Next" title="PyInterpreterState_Next"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyInterpreterState_Next()</span></code></a> let a caller walk through all the existing
|
||
interpreter objects; <a class="reference internal" href="../c-api/init.html#c.PyInterpreterState_ThreadHead" title="PyInterpreterState_ThreadHead"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyInterpreterState_ThreadHead()</span></code></a> and
|
||
<a class="reference internal" href="../c-api/init.html#c.PyThreadState_Next" title="PyThreadState_Next"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyThreadState_Next()</span></code></a> allow looping over all the thread states for a given
|
||
interpreter. (Contributed by David Beazley.)</p></li>
|
||
<li><p>The C-level interface to the garbage collector has been changed to make it
|
||
easier to write extension types that support garbage collection and to debug
|
||
misuses of the functions. Various functions have slightly different semantics,
|
||
so a bunch of functions had to be renamed. Extensions that use the old API will
|
||
still compile but will <em>not</em> participate in garbage collection, so updating them
|
||
for 2.2 should be considered fairly high priority.</p>
|
||
<p>To upgrade an extension module to the new API, perform the following steps:</p>
|
||
</li>
|
||
<li><p>Rename <code class="xref c c-func docutils literal notranslate"><span class="pre">Py_TPFLAGS_GC()</span></code> to <code class="xref c c-func docutils literal notranslate"><span class="pre">PyTPFLAGS_HAVE_GC()</span></code>.</p></li>
|
||
<li><dl class="simple">
|
||
<dt>Use <a class="reference internal" href="../c-api/gcsupport.html#c.PyObject_GC_New" title="PyObject_GC_New"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_New()</span></code></a> or <a class="reference internal" href="../c-api/gcsupport.html#c.PyObject_GC_NewVar" title="PyObject_GC_NewVar"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_NewVar()</span></code></a> to allocate</dt><dd><p>objects, and <a class="reference internal" href="../c-api/gcsupport.html#c.PyObject_GC_Del" title="PyObject_GC_Del"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_Del()</span></code></a> to deallocate them.</p>
|
||
</dd>
|
||
</dl>
|
||
</li>
|
||
<li><dl class="simple">
|
||
<dt>Rename <code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_Init()</span></code> to <a class="reference internal" href="../c-api/gcsupport.html#c.PyObject_GC_Track" title="PyObject_GC_Track"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_Track()</span></code></a> and</dt><dd><p><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_Fini()</span></code> to <a class="reference internal" href="../c-api/gcsupport.html#c.PyObject_GC_UnTrack" title="PyObject_GC_UnTrack"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_GC_UnTrack()</span></code></a>.</p>
|
||
</dd>
|
||
</dl>
|
||
</li>
|
||
<li><p>Remove <code class="xref c c-func docutils literal notranslate"><span class="pre">PyGC_HEAD_SIZE()</span></code> from object size calculations.</p></li>
|
||
<li><p>Remove calls to <code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_AS_GC()</span></code> and <code class="xref c c-func docutils literal notranslate"><span class="pre">PyObject_FROM_GC()</span></code>.</p></li>
|
||
<li><p>A new <code class="docutils literal notranslate"><span class="pre">et</span></code> format sequence was added to <a class="reference internal" href="../c-api/arg.html#c.PyArg_ParseTuple" title="PyArg_ParseTuple"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyArg_ParseTuple()</span></code></a>; <code class="docutils literal notranslate"><span class="pre">et</span></code>
|
||
takes both a parameter and an encoding name, and converts the parameter to the
|
||
given encoding if the parameter turns out to be a Unicode string, or leaves it
|
||
alone if it’s an 8-bit string, assuming it to already be in the desired
|
||
encoding. This differs from the <code class="docutils literal notranslate"><span class="pre">es</span></code> format character, which assumes that
|
||
8-bit strings are in Python’s default ASCII encoding and converts them to the
|
||
specified new encoding. (Contributed by M.-A. Lemburg, and used for the MBCS
|
||
support on Windows described in the following section.)</p></li>
|
||
<li><p>A different argument parsing function, <a class="reference internal" href="../c-api/arg.html#c.PyArg_UnpackTuple" title="PyArg_UnpackTuple"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyArg_UnpackTuple()</span></code></a>, has been
|
||
added that’s simpler and presumably faster. Instead of specifying a format
|
||
string, the caller simply gives the minimum and maximum number of arguments
|
||
expected, and a set of pointers to <a class="reference internal" href="../c-api/structures.html#c.PyObject" title="PyObject"><code class="xref c c-type docutils literal notranslate"><span class="pre">PyObject*</span></code></a> variables that will be
|
||
filled in with argument values.</p></li>
|
||
<li><p>Two new flags <a class="reference internal" href="../c-api/structures.html#METH_NOARGS" title="METH_NOARGS"><code class="xref py py-const docutils literal notranslate"><span class="pre">METH_NOARGS</span></code></a> and <a class="reference internal" href="../c-api/structures.html#METH_O" title="METH_O"><code class="xref py py-const docutils literal notranslate"><span class="pre">METH_O</span></code></a> are available in method
|
||
definition tables to simplify implementation of methods with no arguments or a
|
||
single untyped argument. Calling such methods is more efficient than calling a
|
||
corresponding method that uses <a class="reference internal" href="../c-api/structures.html#METH_VARARGS" title="METH_VARARGS"><code class="xref py py-const docutils literal notranslate"><span class="pre">METH_VARARGS</span></code></a>. Also, the old
|
||
<code class="xref py py-const docutils literal notranslate"><span class="pre">METH_OLDARGS</span></code> style of writing C methods is now officially deprecated.</p></li>
|
||
<li><p>Two new wrapper functions, <a class="reference internal" href="../c-api/conversion.html#c.PyOS_snprintf" title="PyOS_snprintf"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyOS_snprintf()</span></code></a> and <a class="reference internal" href="../c-api/conversion.html#c.PyOS_vsnprintf" title="PyOS_vsnprintf"><code class="xref c c-func docutils literal notranslate"><span class="pre">PyOS_vsnprintf()</span></code></a>
|
||
were added to provide cross-platform implementations for the relatively new
|
||
<code class="xref c c-func docutils literal notranslate"><span class="pre">snprintf()</span></code> and <code class="xref c c-func docutils literal notranslate"><span class="pre">vsnprintf()</span></code> C lib APIs. In contrast to the standard
|
||
<code class="xref c c-func docutils literal notranslate"><span class="pre">sprintf()</span></code> and <code class="xref c c-func docutils literal notranslate"><span class="pre">vsprintf()</span></code> functions, the Python versions check the
|
||
bounds of the buffer used to protect against buffer overruns. (Contributed by
|
||
M.-A. Lemburg.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../c-api/tuple.html#c._PyTuple_Resize" title="_PyTuple_Resize"><code class="xref c c-func docutils literal notranslate"><span class="pre">_PyTuple_Resize()</span></code></a> function has lost an unused parameter, so now it
|
||
takes 2 parameters instead of 3. The third argument was never used, and can
|
||
simply be discarded when porting code from earlier versions to Python 2.2.</p></li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="other-changes-and-fixes">
|
||
<h2>Other Changes and Fixes<a class="headerlink" href="#other-changes-and-fixes" title="Permalink to this headline">¶</a></h2>
|
||
<p>As usual there were a bunch of other improvements and bugfixes scattered
|
||
throughout the source tree. A search through the CVS change logs finds there
|
||
were 527 patches applied and 683 bugs fixed between Python 2.1 and 2.2; 2.2.1
|
||
applied 139 patches and fixed 143 bugs; 2.2.2 applied 106 patches and fixed 82
|
||
bugs. These figures are likely to be underestimates.</p>
|
||
<p>Some of the more notable changes are:</p>
|
||
<ul>
|
||
<li><p>The code for the MacOS port for Python, maintained by Jack Jansen, is now kept
|
||
in the main Python CVS tree, and many changes have been made to support MacOS X.</p>
|
||
<p>The most significant change is the ability to build Python as a framework,
|
||
enabled by supplying the <code class="xref std std-option docutils literal notranslate"><span class="pre">--enable-framework</span></code> option to the configure
|
||
script when compiling Python. According to Jack Jansen, “This installs a
|
||
self-contained Python installation plus the OS X framework “glue” into
|
||
<code class="file docutils literal notranslate"><span class="pre">/Library/Frameworks/Python.framework</span></code> (or another location of choice).
|
||
For now there is little immediate added benefit to this (actually, there is the
|
||
disadvantage that you have to change your PATH to be able to find Python), but
|
||
it is the basis for creating a full-blown Python application, porting the
|
||
MacPython IDE, possibly using Python as a standard OSA scripting language and
|
||
much more.”</p>
|
||
<p>Most of the MacPython toolbox modules, which interface to MacOS APIs such as
|
||
windowing, QuickTime, scripting, etc. have been ported to OS X, but they’ve been
|
||
left commented out in <code class="file docutils literal notranslate"><span class="pre">setup.py</span></code>. People who want to experiment with
|
||
these modules can uncomment them manually.</p>
|
||
</li>
|
||
<li><p>Keyword arguments passed to built-in functions that don’t take them now cause 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 “<em>function</em> takes no
|
||
keyword arguments”.</p></li>
|
||
<li><p>Weak references, added in Python 2.1 as an extension module, are now part of
|
||
the core because they’re used in the implementation of new-style classes. The
|
||
<a class="reference internal" href="../library/exceptions.html#ReferenceError" title="ReferenceError"><code class="xref py py-exc docutils literal notranslate"><span class="pre">ReferenceError</span></code></a> exception has therefore moved from the <a class="reference internal" href="../library/weakref.html#module-weakref" title="weakref: Support for weak references and weak dictionaries."><code class="xref py py-mod docutils literal notranslate"><span class="pre">weakref</span></code></a>
|
||
module to become a built-in exception.</p></li>
|
||
<li><p>A new script, <code class="file docutils literal notranslate"><span class="pre">Tools/scripts/cleanfuture.py</span></code> by Tim Peters,
|
||
automatically removes obsolete <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statements from Python source
|
||
code.</p></li>
|
||
<li><p>An additional <em>flags</em> argument has been added to the built-in function
|
||
<a class="reference internal" href="../library/functions.html#compile" title="compile"><code class="xref py py-func docutils literal notranslate"><span class="pre">compile()</span></code></a>, so the behaviour of <code class="docutils literal notranslate"><span class="pre">__future__</span></code> statements can now be
|
||
correctly observed in simulated shells, such as those presented by IDLE and
|
||
other development environments. This is described in <span class="target" id="index-22"></span><a class="pep reference external" href="https://www.python.org/dev/peps/pep-0264"><strong>PEP 264</strong></a>. (Contributed
|
||
by Michael Hudson.)</p></li>
|
||
<li><p>The new license introduced with Python 1.6 wasn’t GPL-compatible. This is
|
||
fixed by some minor textual changes to the 2.2 license, so it’s now legal to
|
||
embed Python inside a GPLed program again. Note that Python itself is not
|
||
GPLed, but instead is under a license that’s essentially equivalent to the BSD
|
||
license, same as it always was. The license changes were also applied to the
|
||
Python 2.0.1 and 2.1.1 releases.</p></li>
|
||
<li><p>When presented with a Unicode filename on Windows, Python will now convert it
|
||
to an MBCS encoded string, as used by the Microsoft file APIs. As MBCS is
|
||
explicitly used by the file APIs, Python’s choice of ASCII as the default
|
||
encoding turns out to be an annoyance. On Unix, the locale’s character set is
|
||
used if <code class="docutils literal notranslate"><span class="pre">locale.nl_langinfo(CODESET)</span></code> is available. (Windows support was
|
||
contributed by Mark Hammond with assistance from Marc-André Lemburg. Unix
|
||
support was added by Martin von Löwis.)</p></li>
|
||
<li><p>Large file support is now enabled on Windows. (Contributed by Tim Peters.)</p></li>
|
||
<li><p>The <code class="file docutils literal notranslate"><span class="pre">Tools/scripts/ftpmirror.py</span></code> script now parses a <code class="file docutils literal notranslate"><span class="pre">.netrc</span></code>
|
||
file, if you have one. (Contributed by Mike Romberg.)</p></li>
|
||
<li><p>Some features of the object returned by the <code class="xref py py-func docutils literal notranslate"><span class="pre">xrange()</span></code> function are now
|
||
deprecated, and trigger warnings when they’re accessed; they’ll disappear in
|
||
Python 2.3. <code class="xref py py-class docutils literal notranslate"><span class="pre">xrange</span></code> objects tried to pretend they were full sequence
|
||
types by supporting slicing, sequence multiplication, and the <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, but these features were rarely used and therefore buggy. The
|
||
<code class="xref py py-meth docutils literal notranslate"><span class="pre">tolist()</span></code> method and the <code class="xref py py-attr docutils literal notranslate"><span class="pre">start</span></code>, <code class="xref py py-attr docutils literal notranslate"><span class="pre">stop</span></code>, and <code class="xref py py-attr docutils literal notranslate"><span class="pre">step</span></code>
|
||
attributes are also being deprecated. At the C level, the fourth argument to
|
||
the <code class="xref c c-func docutils literal notranslate"><span class="pre">PyRange_New()</span></code> function, <code class="docutils literal notranslate"><span class="pre">repeat</span></code>, has also been deprecated.</p></li>
|
||
<li><p>There were a bunch of patches to the dictionary implementation, mostly to fix
|
||
potential core dumps if a dictionary contains objects that sneakily changed
|
||
their hash value, or mutated the dictionary they were contained in. For a while
|
||
python-dev fell into a gentle rhythm of Michael Hudson finding a case that
|
||
dumped core, Tim Peters fixing the bug, Michael finding another case, and round
|
||
and round it went.</p></li>
|
||
<li><p>On Windows, Python can now be compiled with Borland C thanks to a number of
|
||
patches contributed by Stephen Hansen, though the result isn’t fully functional
|
||
yet. (But this <em>is</em> progress…)</p></li>
|
||
<li><p>Another Windows enhancement: Wise Solutions generously offered PythonLabs use
|
||
of their InstallerMaster 8.1 system. Earlier PythonLabs Windows installers used
|
||
Wise 5.0a, which was beginning to show its age. (Packaged up by Tim Peters.)</p></li>
|
||
<li><p>Files ending in <code class="docutils literal notranslate"><span class="pre">.pyw</span></code> can now be imported on Windows. <code class="docutils literal notranslate"><span class="pre">.pyw</span></code> is a
|
||
Windows-only thing, used to indicate that a script needs to be run using
|
||
PYTHONW.EXE instead of PYTHON.EXE in order to prevent a DOS console from popping
|
||
up to display the output. This patch makes it possible to import such scripts,
|
||
in case they’re also usable as modules. (Implemented by David Bolen.)</p></li>
|
||
<li><p>On platforms where Python uses the C <code class="xref c c-func docutils literal notranslate"><span class="pre">dlopen()</span></code> function to load
|
||
extension modules, it’s now possible to set the flags used by <code class="xref c c-func docutils literal notranslate"><span class="pre">dlopen()</span></code>
|
||
using the <a class="reference internal" href="../library/sys.html#sys.getdlopenflags" title="sys.getdlopenflags"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.getdlopenflags()</span></code></a> and <a class="reference internal" href="../library/sys.html#sys.setdlopenflags" title="sys.setdlopenflags"><code class="xref py py-func docutils literal notranslate"><span class="pre">sys.setdlopenflags()</span></code></a> functions.
|
||
(Contributed by Bram Stolk.)</p></li>
|
||
<li><p>The <a class="reference internal" href="../library/functions.html#pow" title="pow"><code class="xref py py-func docutils literal notranslate"><span class="pre">pow()</span></code></a> built-in function no longer supports 3 arguments when
|
||
floating-point numbers are supplied. <code class="docutils literal notranslate"><span class="pre">pow(x,</span> <span class="pre">y,</span> <span class="pre">z)</span></code> returns <code class="docutils literal notranslate"><span class="pre">(x**y)</span> <span class="pre">%</span> <span class="pre">z</span></code>,
|
||
but this is never useful for floating point numbers, and the final result varies
|
||
unpredictably depending on the platform. A call such as <code class="docutils literal notranslate"><span class="pre">pow(2.0,</span> <span class="pre">8.0,</span> <span class="pre">7.0)</span></code>
|
||
will now raise 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.</p></li>
|
||
</ul>
|
||
</div>
|
||
<div class="section" id="acknowledgements">
|
||
<h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Permalink to this headline">¶</a></h2>
|
||
<p>The author would like to thank the following people for offering suggestions,
|
||
corrections and assistance with various drafts of this article: Fred Bremmer,
|
||
Keith Briggs, Andrew Dalke, Fred L. Drake, Jr., Carel Fellinger, David Goodger,
|
||
Mark Hammond, Stephen Hansen, Michael Hudson, Jack Jansen, Marc-André Lemburg,
|
||
Martin von Löwis, Fredrik Lundh, Michael McLay, Nick Mathewson, Paul Moore,
|
||
Gustavo Niemeyer, Don O’Donnell, Joonas Paalasma, Tim Peters, Jens Quade, Tom
|
||
Reinhardt, Neil Schemenauer, Guido van Rossum, Greg Ward, Edward Welbourne.</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.2</a><ul>
|
||
<li><a class="reference internal" href="#introduction">Introduction</a></li>
|
||
<li><a class="reference internal" href="#peps-252-and-253-type-and-class-changes">PEPs 252 and 253: Type and Class Changes</a><ul>
|
||
<li><a class="reference internal" href="#old-and-new-classes">Old and New Classes</a></li>
|
||
<li><a class="reference internal" href="#descriptors">Descriptors</a></li>
|
||
<li><a class="reference internal" href="#multiple-inheritance-the-diamond-rule">Multiple Inheritance: The Diamond Rule</a></li>
|
||
<li><a class="reference internal" href="#attribute-access">Attribute Access</a></li>
|
||
<li><a class="reference internal" href="#related-links">Related Links</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#pep-234-iterators">PEP 234: Iterators</a></li>
|
||
<li><a class="reference internal" href="#pep-255-simple-generators">PEP 255: Simple Generators</a></li>
|
||
<li><a class="reference internal" href="#pep-237-unifying-long-integers-and-integers">PEP 237: Unifying Long Integers and Integers</a></li>
|
||
<li><a class="reference internal" href="#pep-238-changing-the-division-operator">PEP 238: Changing the Division Operator</a></li>
|
||
<li><a class="reference internal" href="#unicode-changes">Unicode Changes</a></li>
|
||
<li><a class="reference internal" href="#pep-227-nested-scopes">PEP 227: Nested Scopes</a></li>
|
||
<li><a class="reference internal" href="#new-and-improved-modules">New and Improved Modules</a></li>
|
||
<li><a class="reference internal" href="#interpreter-changes-and-fixes">Interpreter Changes and Fixes</a></li>
|
||
<li><a class="reference internal" href="#other-changes-and-fixes">Other Changes and Fixes</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.3.html"
|
||
title="previous chapter">What’s New in Python 2.3</a></p>
|
||
<h4>Next topic</h4>
|
||
<p class="topless"><a href="2.1.html"
|
||
title="next chapter">What’s New in Python 2.1</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.2.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="2.1.html" title="What’s New in Python 2.1"
|
||
>next</a> |</li>
|
||
<li class="right" >
|
||
<a href="2.3.html" title="What’s New in Python 2.3"
|
||
>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> |