<!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="Content-Type" content="text/html; charset=utf-8" />
<title>What’s New in Python 2.1 — Python v3.2.2 documentation</title>
<link rel="stylesheet" href="../_static/default.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript">
var DOCUMENTATION_OPTIONS = {
URL_ROOT: '../',
VERSION: '3.2.2',
COLLAPSE_INDEX: false,
FILE_SUFFIX: '.html',
HAS_SOURCE: true
};
</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/sidebar.js"></script>
<link rel="search" type="application/opensearchdescription+xml"
title="Search within Python v3.2.2 documentation"
href="../_static/opensearch.xml"/>
<link rel="author" title="About these documents" href="../about.html" />
<link rel="copyright" title="Copyright" href="../copyright.html" />
<link rel="top" title="Python v3.2.2 documentation" href="../index.html" />
<link rel="up" title="What’s New in Python" href="index.html" />
<link rel="next" title="What’s New in Python 2.0" href="2.0.html" />
<link rel="prev" title="What’s New in Python 2.2" href="2.2.html" />
<link rel="shortcut icon" type="image/png" href="../_static/py.png" />
</head>
<body>
<div class="related">
<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.0.html" title="What’s New in Python 2.0"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="2.2.html" title="What’s New in Python 2.2"
accesskey="P">previous</a> |</li>
<li><img src="../_static/py.png" alt=""
style="vertical-align: middle; margin-top: -1px"/></li>
<li><a href="../index.html">Python v3.2.2 documentation</a> »</li>
<li><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">
<div class="section" id="what-s-new-in-python-2-1">
<h1>What’s New in Python 2.1<a class="headerlink" href="#what-s-new-in-python-2-1" 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"><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.1. While there aren’t as
many changes in 2.1 as there were in Python 2.0, there are still some pleasant
surprises in store. 2.1 is the first release to be steered through the use of
Python Enhancement Proposals, or PEPs, so most of the sizable changes have
accompanying PEPs that provide more complete documentation and a design
rationale for the change. This article doesn’t attempt to document the new
features completely, but simply provides an overview of the new features for
Python programmers. Refer to the Python 2.1 documentation, or to the specific
PEP, for more details about any new feature that particularly interests you.</p>
<p>One recent goal of the Python development team has been to accelerate the pace
of new releases, with a new release coming every 6 to 9 months. 2.1 is the first
release to come out at this faster pace, with the first alpha appearing in
January, 3 months after the final version of 2.0 was released.</p>
<p>The final release of Python 2.1 was made on April 17, 2001.</p>
</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>The largest change in Python 2.1 is to Python’s scoping rules. In Python 2.0,
at any given time there are at most three namespaces used to look up variable
names: local, module-level, and the built-in namespace. This often surprised
people because it didn’t match their intuitive expectations. For example, a
nested recursive function definition doesn’t work:</p>
<div class="highlight-python3"><div class="highlight"><pre><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 <tt class="xref py py-func docutils literal"><span class="pre">g()</span></tt> will always raise a <a class="reference internal" href="../library/exceptions.html#NameError" title="NameError"><tt class="xref py py-exc docutils literal"><span class="pre">NameError</span></tt></a> exception, because
the binding of the name <tt class="docutils literal"><span class="pre">g</span></tt> 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"><tt class="xref std std-keyword docutils literal"><span class="pre">lambda</span></tt></a> statement clumsier, and this was a problem in practice.
In code which uses <a class="reference internal" href="../reference/expressions.html#lambda"><tt class="xref std std-keyword docutils literal"><span class="pre">lambda</span></tt></a> you can often find local variables being
copied by passing them as the default values of arguments.</p>
<div class="highlight-python3"><div class="highlight"><pre><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="s">"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.1 is that static scoping has been added
to the language to fix this problem. As a first effect, the <tt class="docutils literal"><span class="pre">name=name</span></tt>
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"><tt class="xref std std-keyword docutils literal"><span class="pre">def</span></tt></a>, <a class="reference internal" href="../reference/compound_stmts.html#class"><tt class="xref std std-keyword docutils literal"><span class="pre">class</span></tt></a>, or <a class="reference internal" href="../reference/simple_stmts.html#import"><tt class="xref std std-keyword docutils literal"><span class="pre">import</span></tt></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 <tt class="docutils literal"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></tt> and
<tt class="docutils literal"><span class="pre">exec</span></tt> statements have been made illegal inside a function scope under
certain conditions. The Python reference manual has said all along that <tt class="docutils literal"><span class="pre">from</span>
<span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></tt> 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. <tt class="docutils literal"><span class="pre">from</span>
<span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></tt> and <tt class="docutils literal"><span class="pre">exec</span></tt> 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"><tt class="xref std std-keyword docutils literal"><span class="pre">lambda</span></tt></a> expressions with free variables, the compiler
will flag this by raising a <a class="reference internal" href="../library/exceptions.html#SyntaxError" title="SyntaxError"><tt class="xref py py-exc docutils literal"><span class="pre">SyntaxError</span></tt></a> exception.</p>
<p>To make the preceding explanation a bit clearer, here’s an example:</p>
<div class="highlight-python3"><div class="highlight"><pre><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="c"># The next line is a syntax error</span>
<span class="n">exec</span> <span class="s">'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 <tt class="docutils literal"><span class="pre">exec</span></tt> statement is a syntax error, since
<tt class="docutils literal"><span class="pre">exec</span></tt> would define a new local variable named <tt class="docutils literal"><span class="pre">x</span></tt> whose value should
be accessed by <tt class="xref py py-func docutils literal"><span class="pre">g()</span></tt>.</p>
<p>This shouldn’t be much of a limitation, since <tt class="docutils literal"><span class="pre">exec</span></tt> is rarely used in
most Python code (and when it is used, it’s often a sign of a poor design
anyway).</p>
<p>Compatibility concerns have led to nested scopes being introduced gradually; in
Python 2.1, they aren’t enabled by default, but can be turned on within a module
by using a future statement as described in PEP 236. (See the following section
for further discussion of PEP 236.) In Python 2.2, nested scopes will become
the default and there will be no way to turn them off, but users will have had
all of 2.1’s lifetime to fix any breakage resulting from their introduction.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-0"></span><a class="pep reference external" href="http://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="pep-236-future-directives">
<h2>PEP 236: __future__ Directives<a class="headerlink" href="#pep-236-future-directives" title="Permalink to this headline">¶</a></h2>
<p>The reaction to nested scopes was widespread concern about the dangers of
breaking code with the 2.1 release, and it was strong enough to make the
Pythoneers take a more conservative approach. This approach consists of
introducing a convention for enabling optional functionality in release N that
will become compulsory in release N+1.</p>
<p>The syntax uses a <tt class="docutils literal"><span class="pre">from...import</span></tt> statement using the reserved module name
<a class="reference internal" href="../library/__future__.html#module-__future__" title="__future__: Future statement definitions"><tt class="xref py py-mod docutils literal"><span class="pre">__future__</span></tt></a>. Nested scopes can be enabled by the following statement:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="kn">from</span> <span class="nn">__future__</span> <span class="k">import</span> <span class="n">nested_scopes</span>
</pre></div>
</div>
<p>While it looks like a normal <a class="reference internal" href="../reference/simple_stmts.html#import"><tt class="xref std std-keyword docutils literal"><span class="pre">import</span></tt></a> statement, it’s not; there are
strict rules on where such a future statement can be put. They can only be at
the top of a module, and must precede any Python code or regular
<a class="reference internal" href="../reference/simple_stmts.html#import"><tt class="xref std std-keyword docutils literal"><span class="pre">import</span></tt></a> statements. This is because such statements can affect how
the Python bytecode compiler parses code and generates bytecode, so they must
precede any statement that will result in bytecodes being produced.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-1"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0236"><strong>PEP 236</strong></a> - Back to the <a class="reference internal" href="../library/__future__.html#module-__future__" title="__future__: Future statement definitions"><tt class="xref py py-mod docutils literal"><span class="pre">__future__</span></tt></a></dt>
<dd>Written by Tim Peters, and primarily implemented by Jeremy Hylton.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-207-rich-comparisons">
<h2>PEP 207: Rich Comparisons<a class="headerlink" href="#pep-207-rich-comparisons" title="Permalink to this headline">¶</a></h2>
<p>In earlier versions, Python’s support for implementing comparisons on user-
defined classes and extension types was quite simple. Classes could implement a
<tt class="xref py py-meth docutils literal"><span class="pre">__cmp__()</span></tt> method that was given two instances of a class, and could only
return 0 if they were equal or +1 or -1 if they weren’t; the method couldn’t
raise an exception or return anything other than a Boolean value. Users of
Numeric Python often found this model too weak and restrictive, because in the
number-crunching programs that numeric Python is used for, it would be more
useful to be able to perform elementwise comparisons of two matrices, returning
a matrix containing the results of a given comparison for each element. If the
two matrices are of different sizes, then the compare has to be able to raise an
exception to signal the error.</p>
<p>In Python 2.1, rich comparisons were added in order to support this need.
Python classes can now individually overload each of the <tt class="docutils literal"><span class="pre"><</span></tt>, <tt class="docutils literal"><span class="pre"><=</span></tt>, <tt class="docutils literal"><span class="pre">></span></tt>,
<tt class="docutils literal"><span class="pre">>=</span></tt>, <tt class="docutils literal"><span class="pre">==</span></tt>, and <tt class="docutils literal"><span class="pre">!=</span></tt> operations. The new magic method names are:</p>
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Operation</th>
<th class="head">Method name</th>
</tr>
</thead>
<tbody valign="top">
<tr><td><tt class="docutils literal"><span class="pre"><</span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__lt__" title="object.__lt__"><tt class="xref py py-meth docutils literal"><span class="pre">__lt__()</span></tt></a></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre"><=</span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__le__" title="object.__le__"><tt class="xref py py-meth docutils literal"><span class="pre">__le__()</span></tt></a></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">></span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__gt__" title="object.__gt__"><tt class="xref py py-meth docutils literal"><span class="pre">__gt__()</span></tt></a></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">>=</span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__ge__" title="object.__ge__"><tt class="xref py py-meth docutils literal"><span class="pre">__ge__()</span></tt></a></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">==</span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__eq__" title="object.__eq__"><tt class="xref py py-meth docutils literal"><span class="pre">__eq__()</span></tt></a></td>
</tr>
<tr><td><tt class="docutils literal"><span class="pre">!=</span></tt></td>
<td><a class="reference internal" href="../reference/datamodel.html#object.__ne__" title="object.__ne__"><tt class="xref py py-meth docutils literal"><span class="pre">__ne__()</span></tt></a></td>
</tr>
</tbody>
</table>
<p>(The magic methods are named after the corresponding Fortran operators <tt class="docutils literal"><span class="pre">.LT.</span></tt>.
<tt class="docutils literal"><span class="pre">.LE.</span></tt>, &c. Numeric programmers are almost certainly quite familiar with
these names and will find them easy to remember.)</p>
<p>Each of these magic methods is of the form <tt class="docutils literal"><span class="pre">method(self,</span> <span class="pre">other)</span></tt>, where
<tt class="docutils literal"><span class="pre">self</span></tt> will be the object on the left-hand side of the operator, while
<tt class="docutils literal"><span class="pre">other</span></tt> will be the object on the right-hand side. For example, the
expression <tt class="docutils literal"><span class="pre">A</span> <span class="pre"><</span> <span class="pre">B</span></tt> will cause <tt class="docutils literal"><span class="pre">A.__lt__(B)</span></tt> to be called.</p>
<p>Each of these magic methods can return anything at all: a Boolean, a matrix, a
list, or any other Python object. Alternatively they can raise an exception if
the comparison is impossible, inconsistent, or otherwise meaningless.</p>
<p>The built-in <tt class="xref py py-func docutils literal"><span class="pre">cmp(A,B)()</span></tt> function can use the rich comparison machinery,
and now accepts an optional argument specifying which comparison operation to
use; this is given as one of the strings <tt class="docutils literal"><span class="pre">"<"</span></tt>, <tt class="docutils literal"><span class="pre">"<="</span></tt>, <tt class="docutils literal"><span class="pre">">"</span></tt>, <tt class="docutils literal"><span class="pre">">="</span></tt>,
<tt class="docutils literal"><span class="pre">"=="</span></tt>, or <tt class="docutils literal"><span class="pre">"!="</span></tt>. If called without the optional third argument,
<tt class="xref py py-func docutils literal"><span class="pre">cmp()</span></tt> will only return -1, 0, or +1 as in previous versions of Python;
otherwise it will call the appropriate method and can return any Python object.</p>
<p>There are also corresponding changes of interest to C programmers; there’s a new
slot <tt class="docutils literal"><span class="pre">tp_richcmp</span></tt> in type objects and an API for performing a given rich
comparison. I won’t cover the C API here, but will refer you to PEP 207, or to
2.1’s C API documentation, for the full list of related functions.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-2"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0207"><strong>PEP 207</strong></a> - Rich Comparisions</dt>
<dd>Written by Guido van Rossum, heavily based on earlier work by David Ascher, and
implemented by Guido van Rossum.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-230-warning-framework">
<h2>PEP 230: Warning Framework<a class="headerlink" href="#pep-230-warning-framework" title="Permalink to this headline">¶</a></h2>
<p>Over its 10 years of existence, Python has accumulated a certain number of
obsolete modules and features along the way. It’s difficult to know when a
feature is safe to remove, since there’s no way of knowing how much code uses it
— perhaps no programs depend on the feature, or perhaps many do. To enable
removing old features in a more structured way, a warning framework was added.
When the Python developers want to get rid of a feature, it will first trigger a
warning in the next version of Python. The following Python version can then
drop the feature, and users will have had a full release cycle to remove uses of
the old feature.</p>
<p>Python 2.1 adds the warning framework to be used in this scheme. It adds a
<a class="reference internal" href="../library/warnings.html#module-warnings" title="warnings: Issue warning messages and control their disposition."><tt class="xref py py-mod docutils literal"><span class="pre">warnings</span></tt></a> module that provide functions to issue warnings, and to filter
out warnings that you don’t want to be displayed. Third-party modules can also
use this framework to deprecate old features that they no longer wish to
support.</p>
<p>For example, in Python 2.1 the <tt class="xref py py-mod docutils literal"><span class="pre">regex</span></tt> module is deprecated, so importing
it causes a warning to be printed:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="gp">>>> </span><span class="kn">import</span> <span class="nn">regex</span>
<span class="go">__main__:1: DeprecationWarning: the regex module</span>
<span class="go"> is deprecated; please use the re module</span>
<span class="go">>>></span>
</pre></div>
</div>
<p>Warnings can be issued by calling the <a class="reference internal" href="../library/warnings.html#warnings.warn" title="warnings.warn"><tt class="xref py py-func docutils literal"><span class="pre">warnings.warn()</span></tt></a> function:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="n">warnings</span><span class="o">.</span><span class="n">warn</span><span class="p">(</span><span class="s">"feature X no longer supported"</span><span class="p">)</span>
</pre></div>
</div>
<p>The first parameter is the warning message; an additional optional parameters
can be used to specify a particular warning category.</p>
<p>Filters can be added to disable certain warnings; a regular expression pattern
can be applied to the message or to the module name in order to suppress a
warning. For example, you may have a program that uses the <tt class="xref py py-mod docutils literal"><span class="pre">regex</span></tt> module
and not want to spare the time to convert it to use the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><tt class="xref py py-mod docutils literal"><span class="pre">re</span></tt></a> module right
now. The warning can be suppressed by calling</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="kn">import</span> <span class="nn">warnings</span>
<span class="n">warnings</span><span class="o">.</span><span class="n">filterwarnings</span><span class="p">(</span><span class="n">action</span> <span class="o">=</span> <span class="s">'ignore'</span><span class="p">,</span>
<span class="n">message</span><span class="o">=</span><span class="s">'.*regex module is deprecated'</span><span class="p">,</span>
<span class="n">category</span><span class="o">=</span><span class="ne">DeprecationWarning</span><span class="p">,</span>
<span class="n">module</span> <span class="o">=</span> <span class="s">'__main__'</span><span class="p">)</span>
</pre></div>
</div>
<p>This adds a filter that will apply only to warnings of the class
<a class="reference internal" href="../library/exceptions.html#DeprecationWarning" title="DeprecationWarning"><tt class="xref py py-class docutils literal"><span class="pre">DeprecationWarning</span></tt></a> triggered in the <a class="reference internal" href="../library/__main__.html#module-__main__" title="__main__: The environment where the top-level script is run."><tt class="xref py py-mod docutils literal"><span class="pre">__main__</span></tt></a> module, and applies
a regular expression to only match the message about the <tt class="xref py py-mod docutils literal"><span class="pre">regex</span></tt> module
being deprecated, and will cause such warnings to be ignored. Warnings can also
be printed only once, printed every time the offending code is executed, or
turned into exceptions that will cause the program to stop (unless the
exceptions are caught in the usual way, of course).</p>
<p>Functions were also added to Python’s C API for issuing warnings; refer to PEP
230 or to Python’s API documentation for the details.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-3"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0005"><strong>PEP 5</strong></a> - Guidelines for Language Evolution</dt>
<dd>Written by Paul Prescod, to specify procedures to be followed when removing old
features from Python. The policy described in this PEP hasn’t been officially
adopted, but the eventual policy probably won’t be too different from Prescod’s
proposal.</dd>
<dt><span class="target" id="index-4"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0230"><strong>PEP 230</strong></a> - Warning Framework</dt>
<dd>Written and implemented by Guido van Rossum.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-229-new-build-system">
<h2>PEP 229: New Build System<a class="headerlink" href="#pep-229-new-build-system" title="Permalink to this headline">¶</a></h2>
<p>When compiling Python, the user had to go in and edit the <tt class="file docutils literal"><span class="pre">Modules/Setup</span></tt>
file in order to enable various additional modules; the default set is
relatively small and limited to modules that compile on most Unix platforms.
This means that on Unix platforms with many more features, most notably Linux,
Python installations often don’t contain all useful modules they could.</p>
<p>Python 2.0 added the Distutils, a set of modules for distributing and installing
extensions. In Python 2.1, the Distutils are used to compile much of the
standard library of extension modules, autodetecting which ones are supported on
the current machine. It’s hoped that this will make Python installations easier
and more featureful.</p>
<p>Instead of having to edit the <tt class="file docutils literal"><span class="pre">Modules/Setup</span></tt> file in order to enable
modules, a <tt class="file docutils literal"><span class="pre">setup.py</span></tt> script in the top directory of the Python source
distribution is run at build time, and attempts to discover which modules can be
enabled by examining the modules and header files on the system. If a module is
configured in <tt class="file docutils literal"><span class="pre">Modules/Setup</span></tt>, the <tt class="file docutils literal"><span class="pre">setup.py</span></tt> script won’t attempt
to compile that module and will defer to the <tt class="file docutils literal"><span class="pre">Modules/Setup</span></tt> file’s
contents. This provides a way to specific any strange command-line flags or
libraries that are required for a specific platform.</p>
<p>In another far-reaching change to the build mechanism, Neil Schemenauer
restructured things so Python now uses a single makefile that isn’t recursive,
instead of makefiles in the top directory and in each of the <tt class="file docutils literal"><span class="pre">Python/</span></tt>,
<tt class="file docutils literal"><span class="pre">Parser/</span></tt>, <tt class="file docutils literal"><span class="pre">Objects/</span></tt>, and <tt class="file docutils literal"><span class="pre">Modules/</span></tt> subdirectories. This
makes building Python faster and also makes hacking the Makefiles clearer and
simpler.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-5"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0229"><strong>PEP 229</strong></a> - Using Distutils to Build Python</dt>
<dd>Written and implemented by A.M. Kuchling.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-205-weak-references">
<h2>PEP 205: Weak References<a class="headerlink" href="#pep-205-weak-references" title="Permalink to this headline">¶</a></h2>
<p>Weak references, available through the <a class="reference internal" href="../library/weakref.html#module-weakref" title="weakref: Support for weak references and weak dictionaries."><tt class="xref py py-mod docutils literal"><span class="pre">weakref</span></tt></a> module, are a minor but
useful new data type in the Python programmer’s toolbox.</p>
<p>Storing a reference to an object (say, in a dictionary or a list) has the side
effect of keeping that object alive forever. There are a few specific cases
where this behaviour is undesirable, object caches being the most common one,
and another being circular references in data structures such as trees.</p>
<p>For example, consider a memoizing function that caches the results of another
function <tt class="xref py py-func docutils literal"><span class="pre">f(x)()</span></tt> by storing the function’s argument and its result in a
dictionary:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="n">_cache</span> <span class="o">=</span> <span class="p">{}</span>
<span class="k">def</span> <span class="nf">memoize</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
<span class="k">if</span> <span class="n">_cache</span><span class="o">.</span><span class="n">has_key</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
<span class="k">return</span> <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span>
<span class="n">retval</span> <span class="o">=</span> <span class="n">f</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
<span class="c"># Cache the returned object</span>
<span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span> <span class="o">=</span> <span class="n">retval</span>
<span class="k">return</span> <span class="n">retval</span>
</pre></div>
</div>
<p>This version works for simple things such as integers, but it has a side effect;
the <tt class="docutils literal"><span class="pre">_cache</span></tt> dictionary holds a reference to the return values, so they’ll
never be deallocated until the Python process exits and cleans up This isn’t
very noticeable for integers, but if <tt class="xref py py-func docutils literal"><span class="pre">f()</span></tt> returns an object, or a data
structure that takes up a lot of memory, this can be a problem.</p>
<p>Weak references provide a way to implement a cache that won’t keep objects alive
beyond their time. If an object is only accessible through weak references, the
object will be deallocated and the weak references will now indicate that the
object it referred to no longer exists. A weak reference to an object <em>obj</em> is
created by calling <tt class="docutils literal"><span class="pre">wr</span> <span class="pre">=</span> <span class="pre">weakref.ref(obj)</span></tt>. The object being referred to is
returned by calling the weak reference as if it were a function: <tt class="docutils literal"><span class="pre">wr()</span></tt>. It
will return the referenced object, or <tt class="xref docutils literal"><span class="pre">None</span></tt> if the object no longer exists.</p>
<p>This makes it possible to write a <tt class="xref py py-func docutils literal"><span class="pre">memoize()</span></tt> function whose cache doesn’t
keep objects alive, by storing weak references in the cache.</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="n">_cache</span> <span class="o">=</span> <span class="p">{}</span>
<span class="k">def</span> <span class="nf">memoize</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
<span class="k">if</span> <span class="n">_cache</span><span class="o">.</span><span class="n">has_key</span><span class="p">(</span><span class="n">x</span><span class="p">):</span>
<span class="n">obj</span> <span class="o">=</span> <span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]()</span>
<span class="c"># If weak reference object still exists,</span>
<span class="c"># return it</span>
<span class="k">if</span> <span class="n">obj</span> <span class="ow">is</span> <span class="ow">not</span> <span class="k">None</span><span class="p">:</span> <span class="k">return</span> <span class="n">obj</span>
<span class="n">retval</span> <span class="o">=</span> <span class="n">f</span><span class="p">(</span><span class="n">x</span><span class="p">)</span>
<span class="c"># Cache a weak reference</span>
<span class="n">_cache</span><span class="p">[</span><span class="n">x</span><span class="p">]</span> <span class="o">=</span> <span class="n">weakref</span><span class="o">.</span><span class="n">ref</span><span class="p">(</span><span class="n">retval</span><span class="p">)</span>
<span class="k">return</span> <span class="n">retval</span>
</pre></div>
</div>
<p>The <a class="reference internal" href="../library/weakref.html#module-weakref" title="weakref: Support for weak references and weak dictionaries."><tt class="xref py py-mod docutils literal"><span class="pre">weakref</span></tt></a> module also allows creating proxy objects which behave like
weak references — an object referenced only by proxy objects is deallocated –
but instead of requiring an explicit call to retrieve the object, the proxy
transparently forwards all operations to the object as long as the object still
exists. If the object is deallocated, attempting to use a proxy will cause a
<a class="reference internal" href="../library/weakref.html#weakref.ReferenceError" title="weakref.ReferenceError"><tt class="xref py py-exc docutils literal"><span class="pre">weakref.ReferenceError</span></tt></a> exception to be raised.</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="n">proxy</span> <span class="o">=</span> <span class="n">weakref</span><span class="o">.</span><span class="n">proxy</span><span class="p">(</span><span class="n">obj</span><span class="p">)</span>
<span class="n">proxy</span><span class="o">.</span><span class="n">attr</span> <span class="c"># Equivalent to obj.attr</span>
<span class="n">proxy</span><span class="o">.</span><span class="n">meth</span><span class="p">()</span> <span class="c"># Equivalent to obj.meth()</span>
<span class="k">del</span> <span class="n">obj</span>
<span class="n">proxy</span><span class="o">.</span><span class="n">attr</span> <span class="c"># raises weakref.ReferenceError</span>
</pre></div>
</div>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-6"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0205"><strong>PEP 205</strong></a> - Weak References</dt>
<dd>Written and implemented by Fred L. Drake, Jr.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-232-function-attributes">
<h2>PEP 232: Function Attributes<a class="headerlink" href="#pep-232-function-attributes" title="Permalink to this headline">¶</a></h2>
<p>In Python 2.1, functions can now have arbitrary information attached to them.
People were often using docstrings to hold information about functions and
methods, because the <tt class="docutils literal"><span class="pre">__doc__</span></tt> attribute was the only way of attaching any
information to a function. For example, in the Zope Web application server,
functions are marked as safe for public access by having a docstring, and in
John Aycock’s SPARK parsing framework, docstrings hold parts of the BNF grammar
to be parsed. This overloading is unfortunate, since docstrings are really
intended to hold a function’s documentation; for example, it means you can’t
properly document functions intended for private use in Zope.</p>
<p>Arbitrary attributes can now be set and retrieved on functions using the regular
Python syntax:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="k">def</span> <span class="nf">f</span><span class="p">():</span> <span class="k">pass</span>
<span class="n">f</span><span class="o">.</span><span class="n">publish</span> <span class="o">=</span> <span class="mi">1</span>
<span class="n">f</span><span class="o">.</span><span class="n">secure</span> <span class="o">=</span> <span class="mi">1</span>
<span class="n">f</span><span class="o">.</span><span class="n">grammar</span> <span class="o">=</span> <span class="s">"A ::= B (C D)*"</span>
</pre></div>
</div>
<p>The dictionary containing attributes can be accessed as the function’s
<tt class="xref py py-attr docutils literal"><span class="pre">__dict__</span></tt>. Unlike the <tt class="xref py py-attr docutils literal"><span class="pre">__dict__</span></tt> attribute of class instances, in
functions you can actually assign a new dictionary to <tt class="xref py py-attr docutils literal"><span class="pre">__dict__</span></tt>, though
the new value is restricted to a regular Python dictionary; you <em>can’t</em> be
tricky and set it to a <tt class="xref py py-class docutils literal"><span class="pre">UserDict</span></tt> instance, or any other random object
that behaves like a mapping.</p>
<div class="admonition-see-also 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="http://www.python.org/dev/peps/pep-0232"><strong>PEP 232</strong></a> - Function Attributes</dt>
<dd>Written and implemented by Barry Warsaw.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-235-importing-modules-on-case-insensitive-platforms">
<h2>PEP 235: Importing Modules on Case-Insensitive Platforms<a class="headerlink" href="#pep-235-importing-modules-on-case-insensitive-platforms" title="Permalink to this headline">¶</a></h2>
<p>Some operating systems have filesystems that are case-insensitive, MacOS and
Windows being the primary examples; on these systems, it’s impossible to
distinguish the filenames <tt class="docutils literal"><span class="pre">FILE.PY</span></tt> and <tt class="docutils literal"><span class="pre">file.py</span></tt>, even though they do store
the file’s name in its original case (they’re case-preserving, too).</p>
<p>In Python 2.1, the <a class="reference internal" href="../reference/simple_stmts.html#import"><tt class="xref std std-keyword docutils literal"><span class="pre">import</span></tt></a> statement will work to simulate case-
sensitivity on case-insensitive platforms. Python will now search for the first
case-sensitive match by default, raising an <a class="reference internal" href="../library/exceptions.html#ImportError" title="ImportError"><tt class="xref py py-exc docutils literal"><span class="pre">ImportError</span></tt></a> if no such file
is found, so <tt class="docutils literal"><span class="pre">import</span> <span class="pre">file</span></tt> will not import a module named <tt class="docutils literal"><span class="pre">FILE.PY</span></tt>. Case-
insensitive matching can be requested by setting the <span class="target" id="index-8"></span><a class="reference internal" href="../using/cmdline.html#envvar-PYTHONCASEOK"><tt class="xref std std-envvar docutils literal"><span class="pre">PYTHONCASEOK</span></tt></a>
environment variable before starting the Python interpreter.</p>
</div>
<div class="section" id="pep-217-interactive-display-hook">
<h2>PEP 217: Interactive Display Hook<a class="headerlink" href="#pep-217-interactive-display-hook" title="Permalink to this headline">¶</a></h2>
<p>When using the Python interpreter interactively, the output of commands is
displayed using the built-in <a class="reference internal" href="../library/functions.html#repr" title="repr"><tt class="xref py py-func docutils literal"><span class="pre">repr()</span></tt></a> function. In Python 2.1, the variable
<a class="reference internal" href="../library/sys.html#sys.displayhook" title="sys.displayhook"><tt class="xref py py-func docutils literal"><span class="pre">sys.displayhook()</span></tt></a> can be set to a callable object which will be called
instead of <a class="reference internal" href="../library/functions.html#repr" title="repr"><tt class="xref py py-func docutils literal"><span class="pre">repr()</span></tt></a>. For example, you can set it to a special pretty-
printing function:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="gp">>>> </span><span class="c"># Create a recursive data structure</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">L</span><span class="o">.</span><span class="n">append</span><span class="p">(</span><span class="n">L</span><span class="p">)</span>
<span class="gp">>>> </span><span class="n">L</span> <span class="c"># Show Python's default output</span>
<span class="go">[1, 2, 3, [...]]</span>
<span class="gp">>>> </span><span class="c"># Use pprint.pprint() as the display function</span>
<span class="gp">... </span><span class="kn">import</span> <span class="nn">sys</span><span class="o">,</span> <span class="nn">pprint</span>
<span class="gp">>>> </span><span class="n">sys</span><span class="o">.</span><span class="n">displayhook</span> <span class="o">=</span> <span class="n">pprint</span><span class="o">.</span><span class="n">pprint</span>
<span class="gp">>>> </span><span class="n">L</span>
<span class="go">[1, 2, 3, <Recursion on list with id=135143996>]</span>
<span class="go">>>></span>
</pre></div>
</div>
<div class="admonition-see-also 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="http://www.python.org/dev/peps/pep-0217"><strong>PEP 217</strong></a> - Display Hook for Interactive Use</dt>
<dd>Written and implemented by Moshe Zadka.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-208-new-coercion-model">
<h2>PEP 208: New Coercion Model<a class="headerlink" href="#pep-208-new-coercion-model" title="Permalink to this headline">¶</a></h2>
<p>How numeric coercion is done at the C level was significantly modified. This
will only affect the authors of C extensions to Python, allowing them more
flexibility in writing extension types that support numeric operations.</p>
<p>Extension types can now set the type flag <tt class="docutils literal"><span class="pre">Py_TPFLAGS_CHECKTYPES</span></tt> in their
<tt class="docutils literal"><span class="pre">PyTypeObject</span></tt> structure to indicate that they support the new coercion model.
In such extension types, the numeric slot functions can no longer assume that
they’ll be passed two arguments of the same type; instead they may be passed two
arguments of differing types, and can then perform their own internal coercion.
If the slot function is passed a type it can’t handle, it can indicate the
failure by returning a reference to the <tt class="docutils literal"><span class="pre">Py_NotImplemented</span></tt> singleton value.
The numeric functions of the other type will then be tried, and perhaps they can
handle the operation; if the other type also returns <tt class="docutils literal"><span class="pre">Py_NotImplemented</span></tt>, then
a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><tt class="xref py py-exc docutils literal"><span class="pre">TypeError</span></tt></a> will be raised. Numeric methods written in Python can also
return <tt class="docutils literal"><span class="pre">Py_NotImplemented</span></tt>, causing the interpreter to act as if the method
did not exist (perhaps raising a <a class="reference internal" href="../library/exceptions.html#TypeError" title="TypeError"><tt class="xref py py-exc docutils literal"><span class="pre">TypeError</span></tt></a>, perhaps trying another
object’s numeric methods).</p>
<div class="admonition-see-also 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="http://www.python.org/dev/peps/pep-0208"><strong>PEP 208</strong></a> - Reworking the Coercion Model</dt>
<dd>Written and implemented by Neil Schemenauer, heavily based upon earlier work by
Marc-André Lemburg. Read this to understand the fine points of how numeric
operations will now be processed at the C level.</dd>
</dl>
</div>
</div>
<div class="section" id="pep-241-metadata-in-python-packages">
<h2>PEP 241: Metadata in Python Packages<a class="headerlink" href="#pep-241-metadata-in-python-packages" title="Permalink to this headline">¶</a></h2>
<p>A common complaint from Python users is that there’s no single catalog of all
the Python modules in existence. T. Middleton’s Vaults of Parnassus at
<a class="reference external" href="http://www.vex.net/parnassus/">http://www.vex.net/parnassus/</a> are the largest catalog of Python modules, but
registering software at the Vaults is optional, and many people don’t bother.</p>
<p>As a first small step toward fixing the problem, Python software packaged using
the Distutils <strong class="command">sdist</strong> command will include a file named
<tt class="file docutils literal"><span class="pre">PKG-INFO</span></tt> containing information about the package such as its name,
version, and author (metadata, in cataloguing terminology). PEP 241 contains
the full list of fields that can be present in the <tt class="file docutils literal"><span class="pre">PKG-INFO</span></tt> file. As
people began to package their software using Python 2.1, more and more packages
will include metadata, making it possible to build automated cataloguing systems
and experiment with them. With the result experience, perhaps it’ll be possible
to design a really good catalog and then build support for it into Python 2.2.
For example, the Distutils <strong class="command">sdist</strong> and <strong class="command">bdist_*</strong> commands
could support a <em class="xref std std-option">upload</em> option that would automatically upload your
package to a catalog server.</p>
<p>You can start creating packages containing <tt class="file docutils literal"><span class="pre">PKG-INFO</span></tt> even if you’re not
using Python 2.1, since a new release of the Distutils will be made for users of
earlier Python versions. Version 1.0.2 of the Distutils includes the changes
described in PEP 241, as well as various bugfixes and enhancements. It will be
available from the Distutils SIG at <a class="reference external" href="http://www.python.org/sigs/distutils-sig/">http://www.python.org/sigs/distutils-sig/</a>.</p>
<div class="admonition-see-also admonition seealso">
<p class="first admonition-title">See also</p>
<dl class="last docutils">
<dt><span class="target" id="index-11"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0241"><strong>PEP 241</strong></a> - Metadata for Python Software Packages</dt>
<dd>Written and implemented by A.M. Kuchling.</dd>
<dt><span class="target" id="index-12"></span><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0243"><strong>PEP 243</strong></a> - Module Repository Upload Mechanism</dt>
<dd>Written by Sean Reifschneider, this draft PEP describes a proposed mechanism for
uploading Python packages to a central server.</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">Ka-Ping Yee contributed two new modules: <tt class="xref py py-mod docutils literal"><span class="pre">inspect.py</span></tt>, a module for
getting information about live Python code, and <tt class="xref py py-mod docutils literal"><span class="pre">pydoc.py</span></tt>, a module for
interactively converting docstrings to HTML or text. As a bonus,
<tt class="file docutils literal"><span class="pre">Tools/scripts/pydoc</span></tt>, which is now automatically installed, uses
<tt class="xref py py-mod docutils literal"><span class="pre">pydoc.py</span></tt> to display documentation given a Python module, package, or
class name. For example, <tt class="docutils literal"><span class="pre">pydoc</span> <span class="pre">xml.dom</span></tt> displays the following:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="n">Python</span> <span class="n">Library</span> <span class="n">Documentation</span><span class="p">:</span> <span class="n">package</span> <span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="ow">in</span> <span class="n">xml</span>
<span class="n">NAME</span>
<span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="o">-</span> <span class="n">W3C</span> <span class="n">Document</span> <span class="n">Object</span> <span class="n">Model</span> <span class="n">implementation</span> <span class="k">for</span> <span class="n">Python</span><span class="o">.</span>
<span class="n">FILE</span>
<span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">local</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">python2</span><span class="o">.</span><span class="mi">1</span><span class="o">/</span><span class="n">xml</span><span class="o">/</span><span class="n">dom</span><span class="o">/</span><span class="n">__init__</span><span class="o">.</span><span class="n">pyc</span>
<span class="n">DESCRIPTION</span>
<span class="n">The</span> <span class="n">Python</span> <span class="n">mapping</span> <span class="n">of</span> <span class="n">the</span> <span class="n">Document</span> <span class="n">Object</span> <span class="n">Model</span> <span class="ow">is</span> <span class="n">documented</span> <span class="ow">in</span> <span class="n">the</span>
<span class="n">Python</span> <span class="n">Library</span> <span class="n">Reference</span> <span class="ow">in</span> <span class="n">the</span> <span class="n">section</span> <span class="n">on</span> <span class="n">the</span> <span class="n">xml</span><span class="o">.</span><span class="n">dom</span> <span class="n">package</span><span class="o">.</span>
<span class="n">This</span> <span class="n">package</span> <span class="n">contains</span> <span class="n">the</span> <span class="n">following</span> <span class="n">modules</span><span class="p">:</span>
<span class="o">...</span>
</pre></div>
</div>
<p><tt class="file docutils literal"><span class="pre">pydoc</span></tt> also includes a Tk-based interactive help browser. <tt class="file docutils literal"><span class="pre">pydoc</span></tt>
quickly becomes addictive; try it out!</p>
</li>
<li><p class="first">Two different modules for unit testing were added to the standard library.
The <a class="reference internal" href="../library/doctest.html#module-doctest" title="doctest: Test pieces of code within docstrings."><tt class="xref py py-mod docutils literal"><span class="pre">doctest</span></tt></a> module, contributed by Tim Peters, provides a testing
framework based on running embedded examples in docstrings and comparing the
results against the expected output. PyUnit, contributed by Steve Purcell, is a
unit testing framework inspired by JUnit, which was in turn an adaptation of
Kent Beck’s Smalltalk testing framework. See <a class="reference external" href="http://pyunit.sourceforge.net/">http://pyunit.sourceforge.net/</a> for
more information about PyUnit.</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."><tt class="xref py py-mod docutils literal"><span class="pre">difflib</span></tt></a> module contains a class, <tt class="xref py py-class docutils literal"><span class="pre">SequenceMatcher</span></tt>, which
compares two sequences and computes the changes required to transform one
sequence into the other. For example, this module can be used to write a tool
similar to the Unix <strong class="program">diff</strong> program, and in fact the sample program
<tt class="file docutils literal"><span class="pre">Tools/scripts/ndiff.py</span></tt> demonstrates how to write such a script.</p>
</li>
<li><p class="first"><a class="reference internal" href="../library/curses.panel.html#module-curses.panel" title="curses.panel: A panel stack extension that adds depth to curses windows."><tt class="xref py py-mod docutils literal"><span class="pre">curses.panel</span></tt></a>, a wrapper for the panel library, part of ncurses and of
SYSV curses, was contributed by Thomas Gellekum. The panel library provides
windows with the additional feature of depth. Windows can be moved higher or
lower in the depth ordering, and the panel library figures out where panels
overlap and which sections are visible.</p>
</li>
<li><p class="first">The PyXML package has gone through a few releases since Python 2.0, and Python
2.1 includes an updated version of the <tt class="xref py py-mod docutils literal"><span class="pre">xml</span></tt> package. Some of the
noteworthy changes include support for Expat 1.2 and later versions, the ability
for Expat parsers to handle files in any encoding supported by Python, and
various bugfixes for SAX, DOM, and the <tt class="xref py py-mod docutils literal"><span class="pre">minidom</span></tt> module.</p>
</li>
<li><p class="first">Ping also contributed another hook for handling uncaught exceptions.
<a class="reference internal" href="../library/sys.html#sys.excepthook" title="sys.excepthook"><tt class="xref py py-func docutils literal"><span class="pre">sys.excepthook()</span></tt></a> can be set to a callable object. When an exception isn’t
caught by any <a class="reference internal" href="../reference/compound_stmts.html#try"><tt class="xref std std-keyword docutils literal"><span class="pre">try</span></tt></a>...<a class="reference internal" href="../reference/compound_stmts.html#except"><tt class="xref std std-keyword docutils literal"><span class="pre">except</span></tt></a> blocks, the exception will be
passed to <a class="reference internal" href="../library/sys.html#sys.excepthook" title="sys.excepthook"><tt class="xref py py-func docutils literal"><span class="pre">sys.excepthook()</span></tt></a>, which can then do whatever it likes. At the
Ninth Python Conference, Ping demonstrated an application for this hook:
printing an extended traceback that not only lists the stack frames, but also
lists the function arguments and the local variables for each frame.</p>
</li>
<li><p class="first">Various functions in the <a class="reference internal" href="../library/time.html#module-time" title="time: Time access and conversions."><tt class="xref py py-mod docutils literal"><span class="pre">time</span></tt></a> module, such as <tt class="xref py py-func docutils literal"><span class="pre">asctime()</span></tt> and
<tt class="xref py py-func docutils literal"><span class="pre">localtime()</span></tt>, require a floating point argument containing the time in
seconds since the epoch. The most common use of these functions is to work with
the current time, so the floating point argument has been made optional; when a
value isn’t provided, the current time will be used. For example, log file
entries usually need a string containing the current time; in Python 2.1,
<tt class="docutils literal"><span class="pre">time.asctime()</span></tt> can be used, instead of the lengthier
<tt class="docutils literal"><span class="pre">time.asctime(time.localtime(time.time()))</span></tt> that was previously required.</p>
<p>This change was proposed and implemented by Thomas Wouters.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../library/ftplib.html#module-ftplib" title="ftplib: FTP protocol client (requires sockets)."><tt class="xref py py-mod docutils literal"><span class="pre">ftplib</span></tt></a> module now defaults to retrieving files in passive mode,
because passive mode is more likely to work from behind a firewall. This
request came from the Debian bug tracking system, since other Debian packages
use <a class="reference internal" href="../library/ftplib.html#module-ftplib" title="ftplib: FTP protocol client (requires sockets)."><tt class="xref py py-mod docutils literal"><span class="pre">ftplib</span></tt></a> to retrieve files and then don’t work from behind a firewall.
It’s deemed unlikely that this will cause problems for anyone, because Netscape
defaults to passive mode and few people complain, but if passive mode is
unsuitable for your application or network setup, call <tt class="xref py py-meth docutils literal"><span class="pre">set_pasv(0)()</span></tt> on
FTP objects to disable passive mode.</p>
</li>
<li><p class="first">Support for raw socket access has been added to the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><tt class="xref py py-mod docutils literal"><span class="pre">socket</span></tt></a> module,
contributed by Grant Edwards.</p>
</li>
<li><p class="first">The <a class="reference internal" href="../library/profile.html#module-pstats" title="pstats: Statistics object for use with the profiler."><tt class="xref py py-mod docutils literal"><span class="pre">pstats</span></tt></a> module now contains a simple interactive statistics browser
for displaying timing profiles for Python programs, invoked when the module is
run as a script. Contributed by Eric S. Raymond.</p>
</li>
<li><p class="first">A new implementation-dependent function, <tt class="xref py py-func docutils literal"><span class="pre">sys._getframe([depth])()</span></tt>, has
been added to return a given frame object from the current call stack.
<a class="reference internal" href="../library/sys.html#sys._getframe" title="sys._getframe"><tt class="xref py py-func docutils literal"><span class="pre">sys._getframe()</span></tt></a> returns the frame at the top of the call stack; if the
optional integer argument <em>depth</em> is supplied, the function returns the frame
that is <em>depth</em> calls below the top of the stack. For example,
<tt class="docutils literal"><span class="pre">sys._getframe(1)</span></tt> returns the caller’s frame object.</p>
<p>This function is only present in CPython, not in Jython or the .NET
implementation. Use it for debugging, and resist the temptation to put it into
production code.</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>There were relatively few smaller changes made in Python 2.1 due to the shorter
release cycle. A search through the CVS change logs turns up 117 patches
applied, and 136 bugs fixed; both figures are likely to be underestimates. Some
of the more notable changes are:</p>
<ul>
<li><p class="first">A specialized object allocator is now optionally available, that should be
faster than the system <tt class="xref py py-func docutils literal"><span class="pre">malloc()</span></tt> and have less memory overhead. The
allocator uses C’s <tt class="xref py py-func docutils literal"><span class="pre">malloc()</span></tt> function to get large pools of memory, and
then fulfills smaller memory requests from these pools. It can be enabled by
providing the <em class="xref std std-option">--with-pymalloc</em> option to the <strong class="program">configure</strong>
script; see <tt class="file docutils literal"><span class="pre">Objects/obmalloc.c</span></tt> for the implementation details.</p>
<p>Authors of C extension modules should test their code with the object allocator
enabled, because some incorrect code may break, causing core dumps at runtime.
There are a bunch of memory allocation functions in Python’s C API that have
previously been just aliases for the C library’s <tt class="xref py py-func docutils literal"><span class="pre">malloc()</span></tt> and
<tt class="xref py py-func docutils literal"><span class="pre">free()</span></tt>, meaning that if you accidentally called mismatched functions, the
error wouldn’t be noticeable. When the object allocator is enabled, these
functions aren’t aliases of <tt class="xref py py-func docutils literal"><span class="pre">malloc()</span></tt> and <tt class="xref py py-func docutils literal"><span class="pre">free()</span></tt> any more, and
calling the wrong function to free memory will get you a core dump. For
example, if memory was allocated using <tt class="xref py py-func docutils literal"><span class="pre">PyMem_New()</span></tt>, it has to be freed
using <tt class="xref py py-func docutils literal"><span class="pre">PyMem_Del()</span></tt>, not <tt class="xref py py-func docutils literal"><span class="pre">free()</span></tt>. A few modules included with Python
fell afoul of this and had to be fixed; doubtless there are more third-party
modules that will have the same problem.</p>
<p>The object allocator was contributed by Vladimir Marangozov.</p>
</li>
<li><p class="first">The speed of line-oriented file I/O has been improved because people often
complain about its lack of speed, and because it’s often been used as a naïve
benchmark. The <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><tt class="xref py py-meth docutils literal"><span class="pre">readline()</span></tt></a> method of file objects has therefore been
rewritten to be much faster. The exact amount of the speedup will vary from
platform to platform depending on how slow the C library’s <tt class="xref py py-func docutils literal"><span class="pre">getc()</span></tt> was, but
is around 66%, and potentially much faster on some particular operating systems.
Tim Peters did much of the benchmarking and coding for this change, motivated by
a discussion in comp.lang.python.</p>
<p>A new module and method for file objects was also added, contributed by Jeff
Epler. The new method, <tt class="xref py py-meth docutils literal"><span class="pre">xreadlines()</span></tt>, is similar to the existing
<tt class="xref py py-func docutils literal"><span class="pre">xrange()</span></tt> built-in. <tt class="xref py py-func docutils literal"><span class="pre">xreadlines()</span></tt> returns an opaque sequence object
that only supports being iterated over, reading a line on every iteration but
not reading the entire file into memory as the existing <tt class="xref py py-meth docutils literal"><span class="pre">readlines()</span></tt> method
does. You’d use it like this:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="k">for</span> <span class="n">line</span> <span class="ow">in</span> <span class="n">sys</span><span class="o">.</span><span class="n">stdin</span><span class="o">.</span><span class="n">xreadlines</span><span class="p">():</span>
<span class="c"># ... do something for each line ...</span>
<span class="o">...</span>
</pre></div>
</div>
<p>For a fuller discussion of the line I/O changes, see the python-dev summary for
January 1-15, 2001 at <a class="reference external" href="http://www.python.org/dev/summary/2001-01-1/">http://www.python.org/dev/summary/2001-01-1/</a>.</p>
</li>
<li><p class="first">A new method, <tt class="xref py py-meth docutils literal"><span class="pre">popitem()</span></tt>, was added to dictionaries to enable
destructively iterating through the contents of a dictionary; this can be faster
for large dictionaries because there’s no need to construct a list containing
all the keys or values. <tt class="docutils literal"><span class="pre">D.popitem()</span></tt> removes a random <tt class="docutils literal"><span class="pre">(key,</span> <span class="pre">value)</span></tt> pair
from the dictionary <tt class="docutils literal"><span class="pre">D</span></tt> and returns it as a 2-tuple. This was implemented
mostly by Tim Peters and Guido van Rossum, after a suggestion and preliminary
patch by Moshe Zadka.</p>
</li>
<li><p class="first">Modules can now control which names are imported when <tt class="docutils literal"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></tt>
is used, by defining an <tt class="docutils literal"><span class="pre">__all__</span></tt> attribute containing a list of names that
will be imported. One common complaint is that if the module imports other
modules such as <a class="reference internal" href="../library/sys.html#module-sys" title="sys: Access system-specific parameters and functions."><tt class="xref py py-mod docutils literal"><span class="pre">sys</span></tt></a> or <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><tt class="xref py py-mod docutils literal"><span class="pre">string</span></tt></a>, <tt class="docutils literal"><span class="pre">from</span> <span class="pre">module</span> <span class="pre">import</span> <span class="pre">*</span></tt> will add
them to the importing module’s namespace. To fix this, simply list the public
names in <tt class="docutils literal"><span class="pre">__all__</span></tt>:</p>
<div class="highlight-python3"><div class="highlight"><pre><span class="c"># List public names</span>
<span class="n">__all__</span> <span class="o">=</span> <span class="p">[</span><span class="s">'Database'</span><span class="p">,</span> <span class="s">'open'</span><span class="p">]</span>
</pre></div>
</div>
<p>A stricter version of this patch was first suggested and implemented by Ben
Wolfson, but after some python-dev discussion, a weaker final version was
checked in.</p>
</li>
<li><p class="first">Applying <a class="reference internal" href="../library/functions.html#repr" title="repr"><tt class="xref py py-func docutils literal"><span class="pre">repr()</span></tt></a> to strings previously used octal escapes for
non-printable characters; for example, a newline was <tt class="docutils literal"><span class="pre">'\012'</span></tt>. This was a
vestigial trace of Python’s C ancestry, but today octal is of very little
practical use. Ka-Ping Yee suggested using hex escapes instead of octal ones,
and using the <tt class="docutils literal"><span class="pre">\n</span></tt>, <tt class="docutils literal"><span class="pre">\t</span></tt>, <tt class="docutils literal"><span class="pre">\r</span></tt> escapes for the appropriate characters,
and implemented this new formatting.</p>
</li>
<li><p class="first">Syntax errors detected at compile-time can now raise exceptions containing the
filename and line number of the error, a pleasant side effect of the compiler
reorganization done by Jeremy Hylton.</p>
</li>
<li><p class="first">C extensions which import other modules have been changed to use
<tt class="xref py py-func docutils literal"><span class="pre">PyImport_ImportModule()</span></tt>, which means that they will use any import hooks
that have been installed. This is also encouraged for third-party extensions
that need to import some other module from C code.</p>
</li>
<li><p class="first">The size of the Unicode character database was shrunk by another 340K thanks
to Fredrik Lundh.</p>
</li>
<li><p class="first">Some new ports were contributed: MacOS X (by Steven Majewski), Cygwin (by
Jason Tishler); RISCOS (by Dietmar Schwertberger); Unixware 7 (by Billy G.
Allie).</p>
</li>
</ul>
<p>And there’s the usual list of minor bugfixes, minor memory leaks, docstring
edits, and other tweaks, too lengthy to be worth itemizing; see the CVS logs for
the full details if you want them.</p>
</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 on
various drafts of this article: Graeme Cross, David Goodger, Jay Graves, Michael
Hudson, Marc-André Lemburg, Fredrik Lundh, Neil Schemenauer, Thomas Wouters.</p>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar">
<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.1</a><ul>
<li><a class="reference internal" href="#introduction">Introduction</a></li>
<li><a class="reference internal" href="#pep-227-nested-scopes">PEP 227: Nested Scopes</a></li>
<li><a class="reference internal" href="#pep-236-future-directives">PEP 236: __future__ Directives</a></li>
<li><a class="reference internal" href="#pep-207-rich-comparisons">PEP 207: Rich Comparisons</a></li>
<li><a class="reference internal" href="#pep-230-warning-framework">PEP 230: Warning Framework</a></li>
<li><a class="reference internal" href="#pep-229-new-build-system">PEP 229: New Build System</a></li>
<li><a class="reference internal" href="#pep-205-weak-references">PEP 205: Weak References</a></li>
<li><a class="reference internal" href="#pep-232-function-attributes">PEP 232: Function Attributes</a></li>
<li><a class="reference internal" href="#pep-235-importing-modules-on-case-insensitive-platforms">PEP 235: Importing Modules on Case-Insensitive Platforms</a></li>
<li><a class="reference internal" href="#pep-217-interactive-display-hook">PEP 217: Interactive Display Hook</a></li>
<li><a class="reference internal" href="#pep-208-new-coercion-model">PEP 208: New Coercion Model</a></li>
<li><a class="reference internal" href="#pep-241-metadata-in-python-packages">PEP 241: Metadata in Python Packages</a></li>
<li><a class="reference internal" href="#new-and-improved-modules">New and Improved Modules</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.2.html"
title="previous chapter">What’s New in Python 2.2</a></p>
<h4>Next topic</h4>
<p class="topless"><a href="2.0.html"
title="next chapter">What’s New in Python 2.0</a></p>
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../bugs.html">Report a Bug</a></li>
<li><a href="../_sources/whatsnew/2.1.txt"
rel="nofollow">Show Source</a></li>
</ul>
<div id="searchbox" style="display: none">
<h3>Quick search</h3>
<form class="search" action="../search.html" method="get">
<input type="text" name="q" size="18" />
<input type="submit" value="Go" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
<p class="searchtip" style="font-size: 90%">
Enter search terms or a module, class or function name.
</p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related">
<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.0.html" title="What’s New in Python 2.0"
>next</a> |</li>
<li class="right" >
<a href="2.2.html" title="What’s New in Python 2.2"
>previous</a> |</li>
<li><img src="../_static/py.png" alt=""
style="vertical-align: middle; margin-top: -1px"/></li>
<li><a href="../index.html">Python v3.2.2 documentation</a> »</li>
<li><a href="index.html" >What’s New in Python</a> »</li>
</ul>
</div>
<div class="footer">
© <a href="../copyright.html">Copyright</a> 1990-2011, Python Software Foundation.
<br />
The Python Software Foundation is a non-profit corporation.
<a href="http://www.python.org/psf/donations/">Please donate.</a>
<br />
Last updated on Sep 04, 2011.
<a href="../bugs.html">Found a bug</a>?
<br />
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.0.7.
</div>
</body>
</html>
distrib
>
Mandriva
>
2010.1
>
x86_64
>
media
>
contrib-backports
>
by-pkgid
>
3ba3bd1608c672ba2129b098a48e9e4d
>
files
>
908
