D7net
Home
Console
Upload
information
Create File
Create Folder
About
Tools
:
/
usr
/
share
/
devhelp
/
books
/
python2.7
/
whatsnew
/
Filename :
2.2.html
back
Copy
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="X-UA-Compatible" content="IE=Edge" /> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>What’s New in Python 2.2 — Python 2.7.18 documentation</title> <link rel="stylesheet" href="../_static/classic.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 2.7.18 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="file:///usr/share/doc/python2.7/html/whatsnew/2.2.html" /> <script type="text/javascript" src="../_static/copybutton.js"></script> </head><body> <div id="outdated-warning" style="padding: .5em; text-align: center; background-color: #FFBABA; color: #6A0E0E;"> This document is for an old version of Python that is <a href="https://devguide.python.org/devcycle/#end-of-life-branches">no longer supported</a>. You should install the python3 and python3-doc packages and read the <a href="file:///usr/share/doc/python3-doc/html/whatsnew/2.2.html"> Python documentation for the Python3 version packaged in this release</a>. </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" 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> <a href="../index.html">Python 2.7.18 documentation</a> » </li> <li class="nav-item nav-item-1"><a href="index.html" accesskey="U">What’s New in Python</a> »</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> <table class="docutils field-list" frame="void" rules="none"> <col class="field-name" /> <col class="field-body" /> <tbody valign="top"> <tr class="field-odd field"><th class="field-name">Author:</th><td class="field-body">A.M. Kuchling</td> </tr> </tbody> </table> <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 <a class="reference internal" href="../library/userdict.html#module-UserList" title="UserList: Class wrapper for list objects."><code class="xref py py-mod docutils literal notranslate"><span class="pre">UserList</span></code></a> 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 <a class="reference internal" href="../library/userdict.html#UserList.UserList" title="UserList.UserList"><code class="xref py py-class docutils literal notranslate"><span class="pre">UserList</span></code></a> 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>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.</li> <li>It’s now possible to define static and class methods, in addition to the instance methods available in previous versions of Python.</li> <li>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.</li> <li>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.</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-default 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 <a class="reference internal" href="../reference/datamodel.html#__metaclass__" title="__metaclass__"><code class="xref py py-attr docutils literal notranslate"><span class="pre">__metaclass__</span></code></a> — 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="../c-api/object.html#object"><code class="xref std std-keyword 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/functions.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-default 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 <a class="reference internal" href="../library/functions.html#file" title="file"><code class="xref py py-func docutils literal notranslate"><span class="pre">file()</span></code></a> 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-default 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 <a class="reference internal" href="../library/posixfile.html#module-posixfile" title="posixfile: A file-like object with support for locking. (deprecated) (Unix)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">posixfile</span></code></a> 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><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.</li> <li><code class="xref py py-attr docutils literal notranslate"><span class="pre">__doc__</span></code> is the attribute’s docstring.</li> <li><code class="docutils literal notranslate"><span class="pre">__get__(object)</span></code> is a method that retrieves the attribute value from <em>object</em>.</li> <li><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>.</li> <li><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>.</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-default 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-default 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-default 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-default 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>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>].</li> <li>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.</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-default 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 <a class="reference internal" href="../reference/datamodel.html#object.__coerce__" title="object.__coerce__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__coerce__()</span></code></a>, 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-default 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 <code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code> 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 <code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code> to limit the legal attributes to a particular set of names. An example will make this clear:</p> <div class="highlight-default 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#exceptions.AttributeError" title="exceptions.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 <code class="xref py py-attr docutils literal notranslate"><span class="pre">__slots__</span></code>.</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-default 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#exceptions.StopIteration" title="exceptions.StopIteration"><code class="xref py py-exc docutils literal notranslate"><span class="pre">StopIteration</span></code></a> exception.</p> <div class="highlight-default 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-default 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-default 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-default 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="first admonition-title">See also</p> <dl class="last docutils"> <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>Written by Ka-Ping Yee and GvR; implemented by the Python Labs crew, mostly by GvR and Tim Peters.</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-default 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 <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 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 <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> and 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 is that on reaching a <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> 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 <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. (For complicated reasons, 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 isn’t allowed inside the <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> 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 <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> 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-default 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. <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> 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#exceptions.StopIteration" title="exceptions.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-default 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-default 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="first admonition-title">See also</p> <dl class="last docutils"> <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>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.</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#exceptions.TypeError" title="exceptions.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#exceptions.OverflowError" title="exceptions.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-default 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="first admonition-title">See also</p> <dl class="last docutils"> <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>Written by Moshe Zadka and Guido van Rossum. Implemented mostly by Guido van Rossum.</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 class="first">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 class="first">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 class="first">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 class="first">Python 2.2 supports some command-line arguments for testing whether code will work with the changed division semantics. Running python with <a class="reference internal" href="../using/cmdline.html#cmdoption-q"><code class="xref std std-option docutils literal notranslate"><span class="pre">-Q</span> <span class="pre">warn</span></code></a> 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="first admonition-title">See also</p> <dl class="last docutils"> <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>Written by Moshe Zadka and Guido van Rossum. Implemented by Guido van Rossum..</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 <a class="reference internal" href="../library/functions.html#unichr" title="unichr"><code class="xref py py-func docutils literal notranslate"><span class="pre">unichr()</span></code></a> function is expanded accordingly. Using an interpreter compiled to use UCS-2 (a “narrow Python”), values greater than 65535 will still cause <a class="reference internal" href="../library/functions.html#unichr" title="unichr"><code class="xref py py-func docutils literal notranslate"><span class="pre">unichr()</span></code></a> to raise a <a class="reference internal" href="../library/exceptions.html#exceptions.ValueError" title="exceptions.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-default 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 <a class="reference internal" href="../reference/datamodel.html#object.__unicode__" title="object.__unicode__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__unicode__()</span></code></a> 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 <a class="reference internal" href="../reference/datamodel.html#object.__unicode__" title="object.__unicode__"><code class="xref py py-meth docutils literal notranslate"><span class="pre">__unicode__()</span></code></a> 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="first admonition-title">See also</p> <dl class="last docutils"> <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>Written by Paul Prescod.</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-default 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#exceptions.NameError" title="exceptions.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> statement clumsier, and this was a problem in practice. In code which uses <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> you can often find local variables being copied by passing them as the default values of arguments.</p> <div class="highlight-default 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 <a class="reference internal" href="../reference/simple_stmts.html#exec"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">exec</span></code></a> 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 <a class="reference internal" href="../reference/simple_stmts.html#exec"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">exec</span></code></a> 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#exceptions.SyntaxError" title="exceptions.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-default 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 <a class="reference internal" href="../reference/simple_stmts.html#exec"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">exec</span></code></a> statement is a syntax error, since <a class="reference internal" href="../reference/simple_stmts.html#exec"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">exec</span></code></a> 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 <a class="reference internal" href="../reference/simple_stmts.html#exec"><code class="xref std std-keyword docutils literal notranslate"><span class="pre">exec</span></code></a> 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="first admonition-title">See also</p> <dl class="last docutils"> <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>Written and implemented by Jeremy Hylton.</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 class="first">The <a class="reference internal" href="../library/xmlrpclib.html#module-xmlrpclib" title="xmlrpclib: XML-RPC client access."><code class="xref py py-mod docutils literal notranslate"><span class="pre">xmlrpclib</span></code></a> 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-default 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 <a class="reference internal" href="../library/simplexmlrpcserver.html#module-SimpleXMLRPCServer" title="SimpleXMLRPCServer: Basic XML-RPC server implementation."><code class="xref py py-mod docutils literal notranslate"><span class="pre">SimpleXMLRPCServer</span></code></a> module makes it easy to create straightforward XML-RPC servers. See <a class="reference external" href="http://www.xmlrpc.com/">http://www.xmlrpc.com/</a> for more information about XML-RPC.</p> </li> <li><p class="first">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 class="first">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>, <a class="reference internal" href="../library/statvfs.html#module-statvfs" title="statvfs: Constants for interpreting the result of os.statvfs(). (deprecated)"><code class="xref py py-func docutils literal notranslate"><span class="pre">statvfs()</span></code></a>, 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 class="first">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 class="first">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 class="first">Two new format characters were added to the <a class="reference internal" href="../library/struct.html#module-struct" title="struct: Interpret strings 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 class="first">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 class="first">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 class="first">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 class="first">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 class="first">The <a class="reference internal" href="../library/rfc822.html#module-rfc822" title="rfc822: Parse 2822 style mail messages. (deprecated)"><code class="xref py py-mod docutils literal notranslate"><span class="pre">rfc822</span></code></a> 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, including MIME documents."><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 class="first">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 class="first">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 <a class="reference internal" href="../library/string.html#string.letters" title="string.letters"><code class="xref py py-const docutils literal notranslate"><span class="pre">string.letters</span></code></a> to mean the ranges A-Za-z, but that assumption is incorrect when locales are in use, because <a class="reference internal" href="../library/string.html#string.letters" title="string.letters"><code class="xref py py-const docutils literal notranslate"><span class="pre">string.letters</span></code></a> 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 class="first">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 class="first">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: Higher-level threading interface."><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 class="first">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 class="first">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 class="first">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 class="first">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="first docutils"> <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 class="first last">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="first docutils"> <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 class="first last"><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 class="first">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 class="first">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 class="first">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 class="first">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 class="first">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 <a class="reference internal" href="../c-api/structures.html#METH_OLDARGS" title="METH_OLDARGS"><code class="xref py py-const docutils literal notranslate"><span class="pre">METH_OLDARGS</span></code></a> style of writing C methods is now officially deprecated.</p> </li> <li><p class="first">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 class="first">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 class="first">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 class="first">Keyword arguments passed to built-in functions that don’t take them now cause a <a class="reference internal" href="../library/exceptions.html#exceptions.TypeError" title="exceptions.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 class="first">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#exceptions.ReferenceError" title="exceptions.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 class="first">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 class="first">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 class="first">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 class="first">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 class="first">Large file support is now enabled on Windows. (Contributed by Tim Peters.)</p> </li> <li><p class="first">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 class="first">Some features of the object returned by the <a class="reference internal" href="../library/functions.html#xrange" title="xrange"><code class="xref py py-func docutils literal notranslate"><span class="pre">xrange()</span></code></a> function are now deprecated, and trigger warnings when they’re accessed; they’ll disappear in Python 2.3. <a class="reference internal" href="../library/functions.html#xrange" title="xrange"><code class="xref py py-class docutils literal notranslate"><span class="pre">xrange</span></code></a> 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 class="first">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 class="first">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 class="first">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 class="first">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 class="first">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 class="first">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#exceptions.TypeError" title="exceptions.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="../_sources/whatsnew/2.2.rst.txt" rel="nofollow">Show Source</a></li> </ul> </div> <div id="searchbox" style="display: none" role="search"> <h3>Quick search</h3> <div class="searchformwrapper"> <form class="search" action="../search.html" method="get"> <input 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> </div> <script type="text/javascript">$('#searchbox').show(0);</script> </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> <a href="../index.html">Python 2.7.18 documentation</a> » </li> <li class="nav-item nav-item-1"><a href="index.html" >What’s New in Python</a> »</li> </ul> </div> <div class="footer"> © <a href="../copyright.html">Copyright</a> 1990-2024, 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 December 09, 2024. <a href="../bugs.html">Found a bug</a>? <br /> Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.8.5. </div> </body> </html>