EVOLUTION-NINJA

Edit File: 2.2.html

<!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.2 &mdash; Python 2.7.5 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: '2.7.5',
 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 2.7.5 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 2.7.5 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.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" />
 <script type="text/javascript" src="../_static/copybutton.js"></script>

</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.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="http://www.python.org/">Python</a> &raquo;</li>
 <li>
 <a href="../index.html">Python 2.7.5 documentation</a> &raquo;
 </li>

<li><a href="index.html" accesskey="U">What&#8217;s New in Python</a> &raquo;</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-2">
<h1>What&#8217;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>
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.
Python 2.2 can be thought of as the &#8220;cleanup release&#8221;. 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.
This article doesn&#8217;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="http://www.python.org/doc/2.2/lib/lib.html">Python Library
Reference</a> and the <a class="reference external" href="http://www.python.org/doc/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.
</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>
The largest and most far-reaching changes in Python 2.2 are to Python&#8217;s model of
objects and classes. The changes should be backward compatible, so it&#8217;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&#8217;ll provide an overview of the changes and
offer some comments.
A long time ago I wrote a Web page listing flaws in Python&#8217;s design. One of the
most significant flaws was that it&#8217;s impossible to subclass Python types
implemented in C. In particular, it&#8217;s not possible to subclass built-in types,
so you can&#8217;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."><tt class="xref py py-mod docutils literal">UserList</tt></a> module provides a class that supports all of the
methods of lists and that can be subclassed further, but there&#8217;s lots of C code
that expects a regular Python list and won&#8217;t accept a <a class="reference internal" href="../library/userdict.html#module-UserList" title="UserList: Class wrapper for list objects."><tt class="xref py py-class docutils literal">UserList</tt></a>
instance.
Python 2.2 fixes this, and in the process adds some exciting new capabilities.
A brief summary:
<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&#8217;s now possible to define static and class methods, in addition to the
instance methods available in previous versions of Python.</li>
<li>It&#8217;s also possible to automatically call methods on accessing or setting an
instance attribute by using a new mechanism called properties. Many uses
of <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></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 slots, making it possible to safeguard against typos and
perhaps make more optimizations possible in future versions of Python.</li>
</ul>
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&#8217;t
possible in previous versions of Python, but they also make the language more
complicated. Some people have said that they&#8217;ve always recommended Python for
its simplicity, and feel that its simplicity is being lost.
Personally, I think there&#8217;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&#8217;t need to bother learning or teaching them unless they&#8217;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&#8217;s all for the better.
I&#8217;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">Related Links</a>, &#8220;Related Links&#8221;, for
further sources of information about Python 2.2&#8217;s new object model.
<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>
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&#8217;t intended to last forever; eventually old-style classes will be
dropped, possibly in Python 3.0.
So how do you define a new-style class? You do it by subclassing an existing
new-style class. Most of Python&#8217;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"><tt class="xref py py-class docutils literal">object</tt></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"><tt class="xref py py-class docutils literal">object</tt></a>:
<div class="highlight-python"><div class="highlight"><pre>class C(object):
 def __init__ (self):
 ...
 ...
</pre></div>
</div>
This means that <a class="reference internal" href="../reference/compound_stmts.html#class"><tt class="xref std std-keyword docutils literal">class</tt></a> statements that don&#8217;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__"><tt class="xref py py-attr docutils literal">__metaclass__</tt></a> &#8212; see <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0253">PEP 253</a>
for the details &#8212; but it&#8217;s easier to just subclass <a class="reference internal" href="../c-api/object.html#object"><tt class="xref std std-keyword docutils literal">object</tt></a>.)
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"><tt class="xref py py-func docutils literal">int()</tt></a>,
<a class="reference internal" href="../library/functions.html#float" title="float"><tt class="xref py py-func docutils literal">float()</tt></a>, and <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a>. In 2.2, they aren&#8217;t functions any more, but
type objects that behave as factories when called.
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; int
&lt;type &#39;int&#39;&gt;
&gt;&gt;&gt; int(&#39;123&#39;)
123
</pre></div>
</div>
To make the set of types complete, new type objects such as <a class="reference internal" href="../library/stdtypes.html#dict" title="dict"><tt class="xref py py-func docutils literal">dict()</tt></a> and
<a class="reference internal" href="../library/functions.html#file" title="file"><tt class="xref py py-func docutils literal">file()</tt></a> have been added. Here&#8217;s a more interesting example, adding a
<tt class="xref py py-meth docutils literal">lock()</tt> method to file objects:
<div class="highlight-python"><div class="highlight"><pre>class LockableFile(file):
 def lock (self, operation, length=0, start=0, whence=0):
 import fcntl
 return fcntl.lockf(self.fileno(), operation,
 length, start, whence)
</pre></div>
</div>
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)"><tt class="xref py py-mod docutils literal">posixfile</tt></a> module contained a class that emulated all of
a file object&#8217;s methods and also added a <tt class="xref py py-meth docutils literal">lock()</tt> method, but this class
couldn&#8217;t be passed to internal functions that expected a built-in file,
something which is possible with our new <tt class="xref py py-class docutils literal">LockableFile</tt>.
</div>
<div class="section" id="descriptors">
<h3>Descriptors<a class="headerlink" href="#descriptors" title="Permalink to this headline">¶</a></h3>
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 <tt class="xref py py-attr docutils literal">__members__</tt> and <tt class="xref py py-attr docutils literal">__methods__</tt>
attributes that were lists of names, but often the author of an extension type
or a class wouldn&#8217;t bother to define them. You could fall back on inspecting
the <tt class="xref py py-attr docutils literal">__dict__</tt> of an object, but when class inheritance or an arbitrary
<a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></a> hook were in use this could still be inaccurate.
The one big idea underlying the new class model is that an API for describing
the attributes of an object using descriptors has been formalized.
Descriptors specify the value of an attribute, stating whether it&#8217;s a method or
a field. With the descriptor API, static methods and class methods become
possible, as well as more exotic constructs.
Attribute descriptors are objects that live inside class objects, and have a few
attributes of their own:
<ul class="simple">
<li><tt class="xref py py-attr docutils literal">__name__</tt> is the attribute&#8217;s name.</li>
<li><tt class="xref py py-attr docutils literal">__doc__</tt> is the attribute&#8217;s docstring.</li>
<li><tt class="xref py py-meth docutils literal">__get__(object)()</tt> is a method that retrieves the attribute value from
object.</li>
<li><tt class="xref py py-meth docutils literal">__set__(object, value)()</tt> sets the attribute on object to value.</li>
<li><tt class="xref py py-meth docutils literal">__delete__(object, value)()</tt> deletes the value attribute of object.</li>
</ul>
For example, when you write <tt class="docutils literal">obj.x</tt>, the steps that Python actually performs
are:
<div class="highlight-python"><div class="highlight"><pre>descriptor = obj.__class__.x
descriptor.__get__(obj)
</pre></div>
</div>
For methods, <tt class="xref py py-meth docutils literal">descriptor.__get__()</tt> returns a temporary object that&#8217;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&#8217;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:
<div class="highlight-python"><div class="highlight"><pre>class C(object):
 def f(arg1, arg2):
 ...
 f = staticmethod(f)

def g(cls, arg1, arg2):
 ...
 g = classmethod(g)
</pre></div>
</div>
The <a class="reference internal" href="../library/functions.html#staticmethod" title="staticmethod"><tt class="xref py py-func docutils literal">staticmethod()</tt></a> function takes the function <tt class="xref py py-func docutils literal">f()</tt>, 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 (<tt class="docutils literal">def static f</tt>,
<tt class="docutils literal">defstatic f()</tt>, or something like that) but no such syntax has been defined
yet; that&#8217;s been left for future versions of Python.
More new features, such as slots and properties, are also implemented as new
kinds of descriptors, and it&#8217;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:
<div class="highlight-python"><div class="highlight"><pre>from eiffel import eiffelmethod

class C(object):
 def f(self, arg1, arg2):
 # The actual function
 ...
 def pre_f(self):
 # Check preconditions
 ...
 def post_f(self):
 # Check postconditions
 ...

f = eiffelmethod(f, pre_f, post_f)
</pre></div>
</div>
Note that a person using the new <tt class="xref py py-func docutils literal">eiffelmethod()</tt> doesn&#8217;t have to understand
anything about descriptors. This is why I think the new features don&#8217;t increase
the basic complexity of the language. There will be a few wizards who need to
know about it in order to write <tt class="xref py py-func docutils literal">eiffelmethod()</tt> or the ZODB or whatever,
but most users will just write code on top of the resulting libraries and ignore
the implementation details.
</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>
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 <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0253">PEP 253</a> by Guido van Rossum):
<div class="highlight-python"><pre> class A:
 ^ ^ def save(self): ...
 / \
 / \
 / \
 / \
class B class C:
 ^ ^ def save(self): ...
 \ /
 \ /
 \ /
 \ /
 class D</pre>
</div>
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
<tt class="xref py py-meth docutils literal">D.save()</tt> will search the classes <tt class="xref py py-class docutils literal">D</tt>, <tt class="xref py py-class docutils literal">B</tt>, and then
<tt class="xref py py-class docutils literal">A</tt>, where <tt class="xref py py-meth docutils literal">save()</tt> would be found and returned. <tt class="xref py py-meth docutils literal">C.save()</tt>
would never be found at all. This is bad, because if <tt class="xref py py-class docutils literal">C</tt>&#8216;s <tt class="xref py py-meth docutils literal">save()</tt>
method is saving some internal state specific to <tt class="xref py py-class docutils literal">C</tt>, not calling it will
result in that state never getting saved.
New-style classes follow a different algorithm that&#8217;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.)
<ol class="arabic simple">
<li>List all the base classes, following the classic lookup rule and include a
class multiple times if it&#8217;s visited repeatedly. In the above example, the list
of visited classes is [<tt class="xref py py-class docutils literal">D</tt>, <tt class="xref py py-class docutils literal">B</tt>, <tt class="xref py py-class docutils literal">A</tt>, <tt class="xref py py-class docutils literal">C</tt>,
<tt class="xref py py-class docutils literal">A</tt>].</li>
<li>Scan the list for duplicated classes. If any are found, remove all but one
occurrence, leaving the last one in the list. In the above example, the list
becomes [<tt class="xref py py-class docutils literal">D</tt>, <tt class="xref py py-class docutils literal">B</tt>, <tt class="xref py py-class docutils literal">C</tt>, <tt class="xref py py-class docutils literal">A</tt>] after dropping
duplicates.</li>
</ol>
Following this rule, referring to <tt class="xref py py-meth docutils literal">D.save()</tt> will return <tt class="xref py py-meth docutils literal">C.save()</tt>,
which is the behaviour we&#8217;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"><tt class="xref py py-func docutils literal">super()</tt></a>, provides a way
to get at a class&#8217;s superclasses without having to reimplement Python&#8217;s
algorithm. The most commonly used form will be <tt class="xref py py-func docutils literal">super(class, obj)()</tt>, 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,
<tt class="xref py py-class docutils literal">D</tt>&#8216;s <tt class="xref py py-meth docutils literal">save()</tt> method would look like this:
<div class="highlight-python"><div class="highlight"><pre>class D (B,C):
 def save (self):
 # Call superclass .save()
 super(D, self).save()
 # Save D&#39;s private information here
 ...
</pre></div>
</div>
<a class="reference internal" href="../library/functions.html#super" title="super"><tt class="xref py py-func docutils literal">super()</tt></a> can also return unbound superclass objects when called as
<tt class="xref py py-func docutils literal">super(class)()</tt> or <tt class="xref py py-func docutils literal">super(class1, class2)()</tt>, but this probably won&#8217;t
often be useful.
</div>
<div class="section" id="attribute-access">
<h3>Attribute Access<a class="headerlink" href="#attribute-access" title="Permalink to this headline">¶</a></h3>
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__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></a>; most commonly this is done for convenience, to make
code more readable by automatically mapping an attribute access such as
<tt class="docutils literal">obj.parent</tt> into a method call such as <tt class="docutils literal">obj.get_parent</tt>. Python 2.2 adds
some new ways of controlling attribute access.
First, <tt class="xref py py-meth docutils literal">__getattr__(attr_name)()</tt> 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 <tt class="docutils literal">obj.foo</tt> and no attribute named <tt class="docutils literal">foo</tt> is found in the
instance&#8217;s dictionary.
New-style classes also support a new method,
<tt class="xref py py-meth docutils literal">__getattribute__(attr_name)()</tt>. The difference between the two methods is
that <a class="reference internal" href="../reference/datamodel.html#object.__getattribute__" title="object.__getattribute__"><tt class="xref py py-meth docutils literal">__getattribute__()</tt></a> is always called whenever any attribute is
accessed, while the old <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></a> is only called if <tt class="docutils literal">foo</tt> isn&#8217;t
found in the instance&#8217;s dictionary.
However, Python 2.2&#8217;s support for properties 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__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></a> method is
complicated because to avoid recursion you can&#8217;t use regular attribute accesses
inside them, and instead have to mess around with the contents of
<tt class="xref py py-attr docutils literal">__dict__</tt>. <a class="reference internal" href="../reference/datamodel.html#object.__getattr__" title="object.__getattr__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></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__"><tt class="xref py py-meth docutils literal">__repr__()</tt></a> or <a class="reference internal" href="../reference/datamodel.html#object.__coerce__" title="object.__coerce__"><tt class="xref py py-meth docutils literal">__coerce__()</tt></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.
<a class="reference internal" href="../library/functions.html#property" title="property"><tt class="xref py py-class docutils literal">property</tt></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 <tt class="xref py py-attr docutils literal">size</tt> attribute that&#8217;s computed, but also settable, you could
write:
<div class="highlight-python"><pre>class C(object):
 def get_size (self):
 result = ... computation ...
 return result
 def set_size (self, size):
 ... compute something based on the size
 and set internal state appropriately ...

# Define a property. The 'delete this attribute'
 # method is defined as None, so the attribute
 # can't be deleted.
 size = property(get_size, set_size,
 None,
 "Storage size of this instance")</pre>
</div>
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__"><tt class="xref py py-meth docutils literal">__getattr__()</tt></a>/<a class="reference internal" href="../reference/datamodel.html#object.__setattr__" title="object.__setattr__"><tt class="xref py py-meth docutils literal">__setattr__()</tt></a> methods that check for the <tt class="xref py py-attr docutils literal">size</tt>
attribute and handle it specially while retrieving all other attributes from the
instance&#8217;s <tt class="xref py py-attr docutils literal">__dict__</tt>. Accesses to <tt class="xref py py-attr docutils literal">size</tt> 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.
Finally, it&#8217;s possible to constrain the list of attributes that can be
referenced on an object using the new <a class="reference internal" href="../reference/datamodel.html#__slots__" title="__slots__"><tt class="xref py py-attr docutils literal">__slots__</tt></a> class attribute. Python
objects are usually very dynamic; at any time it&#8217;s possible to define a new
attribute on an instance by just doing <tt class="docutils literal">obj.new_attr=1</tt>. A new-style class
can define a class attribute named <a class="reference internal" href="../reference/datamodel.html#__slots__" title="__slots__"><tt class="xref py py-attr docutils literal">__slots__</tt></a> to limit the legal
attributes to a particular set of names. An example will make this clear:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; class C(object):
... __slots__ = (&#39;template&#39;, &#39;name&#39;)
...
&gt;&gt;&gt; obj = C()
&gt;&gt;&gt; print obj.template
None
&gt;&gt;&gt; obj.template = &#39;Test&#39;
&gt;&gt;&gt; print obj.template
Test
&gt;&gt;&gt; obj.newattr = None
Traceback (most recent call last):
 File &quot;&lt;stdin&gt;&quot;, line 1, in ?
AttributeError: &#39;C&#39; object has no attribute &#39;newattr&#39;
</pre></div>
</div>
Note how you get an <a class="reference internal" href="../library/exceptions.html#exceptions.AttributeError" title="exceptions.AttributeError"><tt class="xref py py-exc docutils literal">AttributeError</tt></a> on the attempt to assign to an
attribute not listed in <a class="reference internal" href="../reference/datamodel.html#__slots__" title="__slots__"><tt class="xref py py-attr docutils literal">__slots__</tt></a>.
</div>
<div class="section" id="related-links">
<h3>Related Links<a class="headerlink" href="#related-links" title="Permalink to this headline">¶</a></h3>
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?
<a class="reference external" href="http://www.python.org/2.2/descrintro.html">http://www.python.org/2.2/descrintro.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.
Next, there are two relevant PEPs, <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0252">PEP 252</a> and <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0253">PEP 253</a>. <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0252">PEP 252</a> is
titled &#8220;Making Types Look More Like Classes&#8221;, and covers the descriptor API.
<a class="pep reference external" href="http://www.python.org/dev/peps/pep-0253">PEP 253</a> is titled &#8220;Subtyping Built-in Types&#8221;, and describes the changes to
type objects that make it possible to subtype built-in objects. <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0253">PEP 253</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.
Finally, there&#8217;s the ultimate authority: the source code. Most of the machinery
for the type handling is in <tt class="file docutils literal">Objects/typeobject.c</tt>, but you should only
resort to it after all other avenues have been exhausted, including posting a
question to python-list or python-dev.
</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>
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.
In Python versions up to 2.1, the usual way to make <tt class="docutils literal">for item in obj</tt> work is
to define a <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><tt class="xref py py-meth docutils literal">__getitem__()</tt></a> method that looks something like this:
<div class="highlight-python"><pre>def __getitem__(self, index):
 return &lt;next item&gt;</pre>
</div>
<a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><tt class="xref py py-meth docutils literal">__getitem__()</tt></a> is more properly used to define an indexing operation on an
object so that you can write <tt class="docutils literal">obj[5]</tt> to retrieve the sixth element. It&#8217;s a
bit misleading when you&#8217;re using this only to support <a class="reference internal" href="../reference/compound_stmts.html#for"><tt class="xref std std-keyword docutils literal">for</tt></a> loops.
Consider some file-like object that wants to be looped over; the index
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__"><tt class="xref py py-meth docutils literal">__getitem__()</tt></a> calls will be made with index 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__"><tt class="xref py py-meth docutils literal">__getitem__()</tt></a> method
doesn&#8217;t mean that using <tt class="docutils literal">file[5]</tt> to randomly access the sixth element will
work, though it really should.
In Python 2.2, iteration can be implemented separately, and <a class="reference internal" href="../reference/datamodel.html#object.__getitem__" title="object.__getitem__"><tt class="xref py py-meth docutils literal">__getitem__()</tt></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, <tt class="xref py py-func docutils literal">iter(obj)()</tt>
or <tt class="docutils literal">iter(C, sentinel)</tt>, is used to get an iterator. <tt class="xref py py-func docutils literal">iter(obj)()</tt> returns
an iterator for the object obj, while <tt class="docutils literal">iter(C, sentinel)</tt> returns an
iterator that will invoke the callable object C until it returns sentinel to
signal that the iterator is done.
Python classes can define an <a class="reference internal" href="../reference/datamodel.html#object.__iter__" title="object.__iter__"><tt class="xref py py-meth docutils literal">__iter__()</tt></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 <tt class="docutils literal">self</tt>. In particular, iterators will usually be their
own iterators. Extension types implemented in C can implement a <tt class="xref py py-attr docutils literal">tp_iter</tt>
function in order to return an iterator, and extension types that want to behave
as iterators can define a <tt class="xref py py-attr docutils literal">tp_iternext</tt> function.
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"><tt class="xref py py-meth docutils literal">next()</tt></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"><tt class="xref py py-meth docutils literal">next()</tt></a> should raise the
<a class="reference internal" href="../library/exceptions.html#exceptions.StopIteration" title="exceptions.StopIteration"><tt class="xref py py-exc docutils literal">StopIteration</tt></a> exception.
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; L = [1,2,3]
&gt;&gt;&gt; i = iter(L)
&gt;&gt;&gt; print i
&lt;iterator object at 0x8116870&gt;
&gt;&gt;&gt; i.next()
1
&gt;&gt;&gt; i.next()
2
&gt;&gt;&gt; i.next()
3
&gt;&gt;&gt; i.next()
Traceback (most recent call last):
 File &quot;&lt;stdin&gt;&quot;, line 1, in ?
StopIteration
&gt;&gt;&gt;
</pre></div>
</div>
In 2.2, Python&#8217;s <a class="reference internal" href="../reference/compound_stmts.html#for"><tt class="xref std std-keyword docutils literal">for</tt></a> statement no longer expects a sequence; it
expects something for which <a class="reference internal" href="../library/functions.html#iter" title="iter"><tt class="xref py py-func docutils literal">iter()</tt></a> will return an iterator. For backward
compatibility and convenience, an iterator is automatically constructed for
sequences that don&#8217;t implement <a class="reference internal" href="../reference/datamodel.html#object.__iter__" title="object.__iter__"><tt class="xref py py-meth docutils literal">__iter__()</tt></a> or a <tt class="xref py py-attr docutils literal">tp_iter</tt> slot, so
<tt class="docutils literal">for i in [1,2,3]</tt> will still work. Wherever the Python interpreter loops
over a sequence, it&#8217;s been changed to use the iterator protocol. This means you
can do things like this:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; L = [1,2,3]
&gt;&gt;&gt; i = iter(L)
&gt;&gt;&gt; a,b,c = i
&gt;&gt;&gt; a,b,c
(1, 2, 3)
</pre></div>
</div>
Iterator support has been added to some of Python&#8217;s basic types. Calling
<a class="reference internal" href="../library/functions.html#iter" title="iter"><tt class="xref py py-func docutils literal">iter()</tt></a> on a dictionary will return an iterator which loops over its keys:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; m = {&#39;Jan&#39;: 1, &#39;Feb&#39;: 2, &#39;Mar&#39;: 3, &#39;Apr&#39;: 4, &#39;May&#39;: 5, &#39;Jun&#39;: 6,
... &#39;Jul&#39;: 7, &#39;Aug&#39;: 8, &#39;Sep&#39;: 9, &#39;Oct&#39;: 10, &#39;Nov&#39;: 11, &#39;Dec&#39;: 12}
&gt;&gt;&gt; for key in m: print key, m[key]
...
Mar 3
Feb 2
Aug 8
Sep 9
May 5
Jun 6
Jul 7
Jan 1
Apr 4
Nov 11
Dec 12
Oct 10
</pre></div>
</div>
That&#8217;s just the default behaviour. If you want to iterate over keys, values, or
key/value pairs, you can explicitly call the <tt class="xref py py-meth docutils literal">iterkeys()</tt>,
<tt class="xref py py-meth docutils literal">itervalues()</tt>, or <tt class="xref py py-meth docutils literal">iteritems()</tt> methods to get an appropriate iterator.
In a minor related change, the <a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a> operator now works on dictionaries,
so <tt class="docutils literal">key in dict</tt> is now equivalent to <tt class="docutils literal">dict.has_key(key)</tt>.
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)"><tt class="xref py py-meth docutils literal">readline()</tt></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:
<div class="highlight-python"><div class="highlight"><pre>for line in file:
 # do something for each line
 ...
</pre></div>
</div>
Note that you can only go forward in an iterator; there&#8217;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"><tt class="xref py py-meth docutils literal">next()</tt></a> method.
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0234">PEP 234</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>
Generators are another new feature, one that interacts with the introduction of
iterators.
You&#8217;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"><tt class="xref std std-keyword docutils literal">return</tt></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&#8217;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.
Here&#8217;s the simplest example of a generator function:
<div class="highlight-python"><div class="highlight"><pre>def generate_ints(N):
 for i in range(N):
 yield i
</pre></div>
</div>
A new keyword, <a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a>, was introduced for generators. Any function
containing a <a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a> statement is a generator function; this is
detected by Python&#8217;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 <tt class="docutils literal">from __future__ import generators</tt>
statement near the top of the module&#8217;s source code. In Python 2.3 this
statement will become unnecessary.
When you call a generator function, it doesn&#8217;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"><tt class="xref std std-keyword docutils literal">yield</tt></a> statement, the generator outputs the value of <tt class="docutils literal">i</tt>,
similar to a <a class="reference internal" href="../reference/simple_stmts.html#return"><tt class="xref std std-keyword docutils literal">return</tt></a> statement. The big difference between
<a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a> and a <a class="reference internal" href="../reference/simple_stmts.html#return"><tt class="xref std std-keyword docutils literal">return</tt></a> statement is that on reaching a
<a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a> the generator&#8217;s state of execution is suspended and local
variables are preserved. On the next call to the generator&#8217;s <tt class="docutils literal">next()</tt> method,
the function will resume executing immediately after the <a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a>
statement. (For complicated reasons, the <a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a> statement isn&#8217;t
allowed inside the <a class="reference internal" href="../reference/compound_stmts.html#try"><tt class="xref std std-keyword docutils literal">try</tt></a> block of a <a class="reference internal" href="../reference/compound_stmts.html#try"><tt class="xref std std-keyword docutils literal">try</tt></a>...<a class="reference internal" href="../reference/compound_stmts.html#finally"><tt class="xref std std-keyword docutils literal">finally</tt></a> statement; read <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0255">PEP 255</a> for a full explanation of the
interaction between <a class="reference internal" href="../reference/simple_stmts.html#yield"><tt class="xref std std-keyword docutils literal">yield</tt></a> and exceptions.)
Here&#8217;s a sample usage of the <tt class="xref py py-func docutils literal">generate_ints()</tt> generator:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; gen = generate_ints(3)
&gt;&gt;&gt; gen
&lt;generator object at 0x8117f90&gt;
&gt;&gt;&gt; gen.next()
0
&gt;&gt;&gt; gen.next()
1
&gt;&gt;&gt; gen.next()
2
&gt;&gt;&gt; gen.next()
Traceback (most recent call last):
 File &quot;&lt;stdin&gt;&quot;, line 1, in ?
 File &quot;&lt;stdin&gt;&quot;, line 2, in generate_ints
StopIteration
</pre></div>
</div>
You could equally write <tt class="docutils literal">for i in generate_ints(5)</tt>, or <tt class="docutils literal">a,b,c =
generate_ints(3)</tt>.
Inside a generator function, the <a class="reference internal" href="../reference/simple_stmts.html#return"><tt class="xref std std-keyword docutils literal">return</tt></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"><tt class="xref std std-keyword docutils literal">return</tt></a> with a value, such
as <tt class="docutils literal">return 5</tt>, is a syntax error inside a generator function. The end of the
generator&#8217;s results can also be indicated by raising <a class="reference internal" href="../library/exceptions.html#exceptions.StopIteration" title="exceptions.StopIteration"><tt class="xref py py-exc docutils literal">StopIteration</tt></a>
manually, or by just letting the flow of execution fall off the bottom of the
function.
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 <tt class="docutils literal">self.count</tt> to
0, and having the <a class="reference internal" href="../library/functions.html#next" title="next"><tt class="xref py py-meth docutils literal">next()</tt></a> method increment <tt class="docutils literal">self.count</tt> and return it.
However, for a moderately complicated generator, writing a corresponding class
would be much messier. <tt class="file docutils literal">Lib/test/test_generators.py</tt> contains a number of
more interesting examples. The simplest one implements an in-order traversal of
a tree using generators recursively.
<div class="highlight-python"><div class="highlight"><pre># A recursive generator that generates Tree leaves in in-order.
def inorder(t):
 if t:
 for x in inorder(t.left):
 yield x
 yield t.label
 for x in inorder(t.right):
 yield x
</pre></div>
</div>
Two other examples in <tt class="file docutils literal">Lib/test/test_generators.py</tt> produce solutions for
the N-Queens problem (placing $N$ queens on an $NxN$ chess board so that no
queen threatens another) and the Knight&#8217;s Tour (a route that takes a knight to
every square of an $NxN$ chessboard without visiting any square twice).
The idea of generators comes from other programming languages, especially Icon
(<a class="reference external" href="http://www.cs.arizona.edu/icon/">http://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 &#8220;An Overview of the Icon Programming Language&#8221; at
<a class="reference external" href="http://www.cs.arizona.edu/icon/docs/ipd266.htm">http://www.cs.arizona.edu/icon/docs/ipd266.htm</a> gives an idea of what this looks
like:
<div class="highlight-python"><pre>sentence := "Store it in the neighboring harbor"
if (i := find("or", sentence)) &gt; 5 then write(i)</pre>
</div>
In Icon the <tt class="xref py py-func docutils literal">find()</tt> function returns the indexes at which the substring
&#8220;or&#8221; is found: 3, 23, 33. In the <a class="reference internal" href="../reference/compound_stmts.html#if"><tt class="xref std std-keyword docutils literal">if</tt></a> statement, <tt class="docutils literal">i</tt> 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.
Python doesn&#8217;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&#8217;t compulsory; if they don&#8217;t solve any problems that
you have, feel free to ignore them. One novel feature of Python&#8217;s interface as
compared to Icon&#8217;s is that a generator&#8217;s state is represented as a concrete
object (the iterator) that can be passed around to other functions or stored in
a data structure.
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0255">PEP 255</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>
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
<tt class="docutils literal">2**32</tt> bytes, the <tt class="xref py py-meth docutils literal">tell()</tt> 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
<tt class="docutils literal">'abc'[1L:]</tt> would raise a <a class="reference internal" href="../library/exceptions.html#exceptions.TypeError" title="exceptions.TypeError"><tt class="xref py py-exc docutils literal">TypeError</tt></a> exception with the message &#8216;slice
index must be int&#8217;.
Python 2.2 will shift values from short to long integers as required. The &#8216;L&#8217;
suffix is no longer needed to indicate a long integer literal, as now the
compiler will choose the appropriate type. (Using the &#8216;L&#8217; 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"><tt class="xref py py-exc docutils literal">OverflowError</tt></a> will now return a long integer as their result. For
example:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; 1234567890123
1234567890123L
&gt;&gt;&gt; 2 ** 64
18446744073709551616L
</pre></div>
</div>
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"><tt class="xref py py-func docutils literal">type()</tt></a> built-in function, but that&#8217;s
rarely needed.
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0237">PEP 237</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>
The most controversial change in Python 2.2 heralds the start of an effort to
fix an old design flaw that&#8217;s been in Python from the beginning. Currently
Python&#8217;s division operator, <tt class="docutils literal">/</tt>, behaves like C&#8217;s division operator when
presented with two integer arguments: it returns an integer result that&#8217;s
truncated down when there would be a fractional part. For example, <tt class="docutils literal">3/2</tt> is
1, not 1.5, and <tt class="docutils literal">(-1)/2</tt> 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.
(The controversy is over whether this is really a design flaw, and whether
it&#8217;s worth breaking existing code to fix this. It&#8217;s caused endless discussions
on python-dev, and in July 2001 erupted into an storm of acidly sarcastic
postings on comp.lang.python. I won&#8217;t argue for either side here
and will stick to describing what&#8217;s implemented in 2.2. Read <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0238">PEP 238</a> for a
summary of arguments and counter-arguments.)
Because this change might break code, it&#8217;s being introduced very gradually.
Python 2.2 begins the transition, but the switch won&#8217;t be complete until Python
3.0.
First, I&#8217;ll borrow some terminology from <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0238">PEP 238</a>. &#8220;True division&#8221; is the
division that most non-programmers are familiar with: 3/2 is 1.5, 1/4 is 0.25,
and so forth. &#8220;Floor division&#8221; is what Python&#8217;s <tt class="docutils literal">/</tt> operator currently does
when given integer operands; the result is the floor of the value returned by
true division. &#8220;Classic division&#8221; is the current mixed behaviour of <tt class="docutils literal">/</tt>; 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.
Here are the changes 2.2 introduces:
<ul>
<li>A new operator, <tt class="docutils literal">//</tt>, is the floor division operator. (Yes, we know it looks
like C++&#8217;s comment symbol.) <tt class="docutils literal">//</tt> always performs floor division no matter
what the types of its operands are, so <tt class="docutils literal">1 // 2</tt> is 0 and <tt class="docutils literal">1.0 // 2.0</tt> is
also 0.0.
<tt class="docutils literal">//</tt> is always available in Python 2.2; you don&#8217;t need to enable it using a
<tt class="docutils literal">__future__</tt> statement.
</li>
<li>By including a <tt class="docutils literal">from __future__ import division</tt> in a module, the <tt class="docutils literal">/</tt>
operator will be changed to return the result of true division, so <tt class="docutils literal">1/2</tt> is
0.5. Without the <tt class="docutils literal">__future__</tt> statement, <tt class="docutils literal">/</tt> still means classic division.
The default meaning of <tt class="docutils literal">/</tt> will not change until Python 3.0.
</li>
<li>Classes can define methods called <a class="reference internal" href="../reference/datamodel.html#object.__truediv__" title="object.__truediv__"><tt class="xref py py-meth docutils literal">__truediv__()</tt></a> and <a class="reference internal" href="../reference/datamodel.html#object.__floordiv__" title="object.__floordiv__"><tt class="xref py py-meth docutils literal">__floordiv__()</tt></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#PyNumberMethods" title="PyNumberMethods"><tt class="xref c c-type docutils literal">PyNumberMethods</tt></a> structure so extension types can define the two
operators.
</li>
<li>Python 2.2 supports some command-line arguments for testing whether code will
works with the changed division semantics. Running python with -Q
warn will cause a warning to be issued whenever division is applied to two
integers. You can use this to find code that&#8217;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.
</li>
</ul>
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0238">PEP 238</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>
Python&#8217;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 --enable-unicode=ucs4 to the configure script. (It&#8217;s also
possible to specify --disable-unicode to completely disable Unicode
support.)
When built to use UCS-4 (a &#8220;wide Python&#8221;), 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"><tt class="xref py py-func docutils literal">unichr()</tt></a> function is expanded accordingly. Using an interpreter
compiled to use UCS-2 (a &#8220;narrow Python&#8221;), values greater than 65535 will still
cause <a class="reference internal" href="../library/functions.html#unichr" title="unichr"><tt class="xref py py-func docutils literal">unichr()</tt></a> to raise a <a class="reference internal" href="../library/exceptions.html#exceptions.ValueError" title="exceptions.ValueError"><tt class="xref py py-exc docutils literal">ValueError</tt></a> exception. This is all
described in <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0261">PEP 261</a>, &#8220;Support for &#8216;wide&#8217; Unicode characters&#8221;; consult it for
further details.
Another change is simpler to explain. Since their introduction, Unicode strings
have supported an <tt class="xref py py-meth docutils literal">encode()</tt> method to convert the string to a selected
encoding such as UTF-8 or Latin-1. A symmetric <tt class="xref py py-meth docutils literal">decode([*encoding*])()</tt>
method has been added to 8-bit strings (though not to Unicode strings) in 2.2.
<tt class="xref py py-meth docutils literal">decode()</tt> assumes that the string is in the specified encoding and decodes
it, returning whatever is returned by the codec.
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&#8217;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."><tt class="xref py py-mod docutils literal">zlib</tt></a> module:
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; s = &quot;&quot;&quot;Here is a lengthy piece of redundant, overly verbose,
... and repetitive text.
... &quot;&quot;&quot;
&gt;&gt;&gt; data = s.encode(&#39;zlib&#39;)
&gt;&gt;&gt; data
&#39;x\x9c\r\xc9\xc1\r\x80 \x10\x04\xc0?Ul...&#39;
&gt;&gt;&gt; data.decode(&#39;zlib&#39;)
&#39;Here is a lengthy piece of redundant, overly verbose,\nand repetitive text.\n&#39;
&gt;&gt;&gt; print s.encode(&#39;uu&#39;)
begin 666 &lt;data&gt;
M2&amp;5R92!I&lt;R!A(&amp;QE;F=T:&#39;D@&lt;&amp;EE8V4@;V8@&lt;F5D=6YD86YT+&quot;!O=F5R;&#39;D@
&gt;=F5R8F]S92P*86YD(&#39;)E&lt;&amp;5T:71I=F4@=&amp;5X=&quot;X*

end
&gt;&gt;&gt; &quot;sheesh&quot;.encode(&#39;rot-13&#39;)
&#39;furrfu&#39;
</pre></div>
</div>
To convert a class instance to Unicode, a <a class="reference internal" href="../reference/datamodel.html#object.__unicode__" title="object.__unicode__"><tt class="xref py py-meth docutils literal">__unicode__()</tt></a> method can be
defined by a class, analogous to <a class="reference internal" href="../reference/datamodel.html#object.__str__" title="object.__str__"><tt class="xref py py-meth docutils literal">__str__()</tt></a>.
<tt class="xref py py-meth docutils literal">encode()</tt>, <tt class="xref py py-meth docutils literal">decode()</tt>, and <a class="reference internal" href="../reference/datamodel.html#object.__unicode__" title="object.__unicode__"><tt class="xref py py-meth docutils literal">__unicode__()</tt></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.
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0261">PEP 261</a> - Support for &#8216;wide&#8217; 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>
In Python 2.1, statically nested scopes were added as an optional feature, to be
enabled by a <tt class="docutils literal">from __future__ import nested_scopes</tt> 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
&#8220;What&#8217;s New in Python 2.1&#8221; document; if you read it when 2.1 came out, you can
skip the rest of this section.
The largest change introduced in Python 2.1, and made complete in 2.2, is to
Python&#8217;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&#8217;t match their
intuitive expectations. For example, a nested recursive function definition
doesn&#8217;t work:
<div class="highlight-python"><div class="highlight"><pre>def f():
 ...
 def g(value):
 ...
 return g(value-1) + 1
 ...
</pre></div>
</div>
The function <tt class="xref py py-func docutils literal">g()</tt> will always raise a <a class="reference internal" href="../library/exceptions.html#exceptions.NameError" title="exceptions.NameError"><tt class="xref py py-exc docutils literal">NameError</tt></a> exception, because
the binding of the name <tt class="docutils literal">g</tt> isn&#8217;t in either its local namespace or in the
module-level namespace. This isn&#8217;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">lambda</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">lambda</tt></a> you can often find local variables being
copied by passing them as the default values of arguments.
<div class="highlight-python"><div class="highlight"><pre>def find(self, name):
 &quot;Return list of any entries equal to &#39;name&#39;&quot;
 L = filter(lambda x, name=name: x == name,
 self.list_attribute)
 return L
</pre></div>
</div>
The readability of Python code written in a strongly functional style suffers
greatly as a result.
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 <tt class="docutils literal">name=name</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">def</tt></a>, <a class="reference internal" href="../reference/compound_stmts.html#class"><tt class="xref std std-keyword docutils literal">class</tt></a>, or <a class="reference internal" href="../reference/simple_stmts.html#import"><tt class="xref std std-keyword docutils literal">import</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.
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.
One side effect of the change is that the <tt class="docutils literal">from module import *</tt> and
<a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></a> 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">from
module import *</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">from
module import *</tt> and <a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></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"><tt class="xref std std-keyword docutils literal">lambda</tt></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"><tt class="xref py py-exc docutils literal">SyntaxError</tt></a> exception.
To make the preceding explanation a bit clearer, here&#8217;s an example:
<div class="highlight-python"><div class="highlight"><pre>x = 1
def f():
 # The next line is a syntax error
 exec &#39;x=2&#39;
 def g():
 return x
</pre></div>
</div>
Line 4 containing the <a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></a> statement is a syntax error, since
<a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></a> would define a new local variable named <tt class="docutils literal">x</tt> whose value should
be accessed by <tt class="xref py py-func docutils literal">g()</tt>.
This shouldn&#8217;t be much of a limitation, since <a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></a> is rarely used in
most Python code (and when it is used, it&#8217;s often a sign of a poor design
anyway).
<div class="admonition-see-also admonition seealso">
See also
<dl class="last docutils">
<dt><a class="pep reference external" href="http://www.python.org/dev/peps/pep-0227">PEP 227</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>The <a class="reference internal" href="../library/xmlrpclib.html#module-xmlrpclib" title="xmlrpclib: XML-RPC client access."><tt class="xref py py-mod docutils literal">xmlrpclib</tt></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&#8217;Reilly Network,
and then lists the recent headlines for one channel:
<div class="highlight-python"><div class="highlight"><pre>import xmlrpclib
s = xmlrpclib.Server(
 &#39;http://www.oreillynet.com/meerkat/xml-rpc/server.php&#39;)
channels = s.meerkat.getChannels()
# channels is a list of dictionaries, like this:
# [{&#39;id&#39;: 4, &#39;title&#39;: &#39;Freshmeat Daily News&#39;}
# {&#39;id&#39;: 190, &#39;title&#39;: &#39;32Bits Online&#39;},
# {&#39;id&#39;: 4549, &#39;title&#39;: &#39;3DGamers&#39;}, ... ]

# Get the items for one channel
items = s.meerkat.getItems( {&#39;channel&#39;: 4} )

# &#39;items&#39; is another list of dictionaries, like this:
# [{&#39;link&#39;: &#39;http://freshmeat.net/releases/52719/&#39;,
# &#39;description&#39;: &#39;A utility which converts HTML to XSL FO.&#39;,
# &#39;title&#39;: &#39;html2fo 0.3 (Default)&#39;}, ... ]
</pre></div>
</div>
The <a class="reference internal" href="../library/simplexmlrpcserver.html#module-SimpleXMLRPCServer" title="SimpleXMLRPCServer: Basic XML-RPC server implementation."><tt class="xref py py-mod docutils literal">SimpleXMLRPCServer</tt></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.
</li>
<li>The new <a class="reference internal" href="../library/hmac.html#module-hmac" title="hmac: Keyed-Hashing for Message Authentication (HMAC) implementation for Python."><tt class="xref py py-mod docutils literal">hmac</tt></a> module implements the HMAC algorithm described by
<a class="rfc reference external" href="http://tools.ietf.org/html/rfc2104.html">RFC 2104</a>. (Contributed by Gerhard Häring.)
</li>
<li>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 <tt class="xref py py-attr docutils literal">tm_year</tt>. 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()."><tt class="xref py py-func docutils literal">stat()</tt></a>, <tt class="xref py py-func docutils literal">fstat()</tt>, <a class="reference internal" href="../library/statvfs.html#module-statvfs" title="statvfs: Constants for interpreting the result of os.statvfs(). (deprecated)"><tt class="xref py py-func docutils literal">statvfs()</tt></a>, and <tt class="xref py py-func docutils literal">fstatvfs()</tt> in the
<a class="reference internal" href="../library/os.html#module-os" title="os: Miscellaneous operating system interfaces."><tt class="xref py py-mod docutils literal">os</tt></a> module, and <tt class="xref py py-func docutils literal">localtime()</tt>, <tt class="xref py py-func docutils literal">gmtime()</tt>, and <tt class="xref py py-func docutils literal">strptime()</tt> 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">time</tt></a> module.
For example, to obtain a file&#8217;s size using the old tuples, you&#8217;d end up writing
something like <tt class="docutils literal">file_size = os.stat(filename)[stat.ST_SIZE]</tt>, but now this can
be written more clearly as <tt class="docutils literal">file_size = os.stat(filename).st_size</tt>.
The original patch for this feature was contributed by Nick Mathewson.
</li>
<li>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.)
</li>
<li>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">socket</tt></a> module can be compiled to support IPv6; specify the
--enable-ipv6 option to Python&#8217;s configure script. (Contributed by
Jun-ichiro &#8220;itojun&#8221; Hagino.)
</li>
<li>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."><tt class="xref py py-mod docutils literal">struct</tt></a> module for 64-bit
integers on platforms that support the C <tt class="xref c c-type docutils literal">long long</tt> type. <tt class="docutils literal">q</tt> is for
a signed 64-bit integer, and <tt class="docutils literal">Q</tt> is for an unsigned one. The value is
returned in Python&#8217;s long integer type. (Contributed by Tim Peters.)
</li>
<li>In the interpreter&#8217;s interactive mode, there&#8217;s a new built-in function
<a class="reference internal" href="../library/functions.html#help" title="help"><tt class="xref py py-func docutils literal">help()</tt></a> that uses the <a class="reference internal" href="../library/pydoc.html#module-pydoc" title="pydoc: Documentation generator and online help system."><tt class="xref py py-mod docutils literal">pydoc</tt></a> module introduced in Python 2.1 to
provide interactive help. <tt class="docutils literal">help(object)</tt> displays any available help text
about object. <a class="reference internal" href="../library/functions.html#help" title="help"><tt class="xref py py-func docutils literal">help()</tt></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&#8217;s
<a class="reference internal" href="../library/pydoc.html#module-pydoc" title="pydoc: Documentation generator and online help system."><tt class="xref py py-mod docutils literal">pydoc</tt></a> module.)
</li>
<li>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."><tt class="xref py py-mod docutils literal">re</tt></a> module. For example, the <a class="reference internal" href="../library/re.html#re.sub" title="re.sub"><tt class="xref py py-func docutils literal">re.sub()</tt></a> and
<a class="reference internal" href="../library/re.html#re.split" title="re.split"><tt class="xref py py-func docutils literal">re.split()</tt></a> functions have been rewritten in C. Another contributed patch
speeds up certain Unicode character ranges by a factor of two, and a new
<tt class="xref py py-meth docutils literal">finditer()</tt> 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.)
</li>
<li>The <a class="reference internal" href="../library/smtplib.html#module-smtplib" title="smtplib: SMTP protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">smtplib</tt></a> module now supports <a class="rfc reference external" href="http://tools.ietf.org/html/rfc2487.html">RFC 2487</a>, &#8220;Secure SMTP over TLS&#8221;, so
it&#8217;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)."><tt class="xref py py-mod docutils literal">smtplib</tt></a> also supports SMTP
authentication. (Contributed by Gerhard Häring.)
</li>
<li>The <a class="reference internal" href="../library/imaplib.html#module-imaplib" title="imaplib: IMAP4 protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">imaplib</tt></a> module, maintained by Piers Lauder, has support for several
new extensions: the NAMESPACE extension defined in <a class="rfc reference external" href="http://tools.ietf.org/html/rfc2342.html">RFC 2342</a>, SORT, GETACL and
SETACL. (Contributed by Anthony Baxter and Michel Pelletier.)
</li>
<li>The <a class="reference internal" href="../library/rfc822.html#module-rfc822" title="rfc822: Parse 2822 style mail messages. (deprecated)"><tt class="xref py py-mod docutils literal">rfc822</tt></a> module&#8217;s parsing of email addresses is now compliant with
<a class="rfc reference external" href="http://tools.ietf.org/html/rfc2822.html">RFC 2822</a>, an update to <a class="rfc reference external" href="http://tools.ietf.org/html/rfc822.html">RFC 822</a>. (The module&#8217;s name is not going to be
changed to <tt class="docutils literal">rfc2822</tt>.) 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."><tt class="xref py py-mod docutils literal">email</tt></a>, has also been added for
parsing and generating e-mail messages. (Contributed by Barry Warsaw, and
arising out of his work on Mailman.)
</li>
<li>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">difflib</tt></a> module now contains a new <tt class="xref py py-class docutils literal">Differ</tt> class for
producing human-readable lists of changes (a &#8220;delta&#8221;) between two sequences of
lines of text. There are also two generator functions, <tt class="xref py py-func docutils literal">ndiff()</tt> and
<tt class="xref py py-func docutils literal">restore()</tt>, 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.)
</li>
<li>New constants <tt class="xref py py-const docutils literal">ascii_letters</tt>, <tt class="xref py py-const docutils literal">ascii_lowercase</tt>, and
<tt class="xref py py-const docutils literal">ascii_uppercase</tt> were added to the <a class="reference internal" href="../library/string.html#module-string" title="string: Common string operations."><tt class="xref py py-mod docutils literal">string</tt></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"><tt class="xref py py-const docutils literal">string.letters</tt></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"><tt class="xref py py-const docutils literal">string.letters</tt></a> varies depending on the set of legal
characters defined by the current locale. The buggy modules have all been fixed
to use <tt class="xref py py-const docutils literal">ascii_letters</tt> instead. (Reported by an unknown person; fixed by
Fred L. Drake, Jr.)
</li>
<li>The <a class="reference internal" href="../library/mimetypes.html#module-mimetypes" title="mimetypes: Mapping of filename extensions to MIME types."><tt class="xref py py-mod docutils literal">mimetypes</tt></a> module now makes it easier to use alternative MIME-type
databases by the addition of a <tt class="xref py py-class docutils literal">MimeTypes</tt> class, which takes a list of
filenames to be parsed. (Contributed by Fred L. Drake, Jr.)
</li>
<li>A <tt class="xref py py-class docutils literal">Timer</tt> class was added to the <a class="reference internal" href="../library/threading.html#module-threading" title="threading: Higher-level threading interface."><tt class="xref py py-mod docutils literal">threading</tt></a> module that allows
scheduling an activity to happen at some future time. (Contributed by Itamar
Shtull-Trauring.)
</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>
Some of the changes only affect people who deal with the Python interpreter at
the C level because they&#8217;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.
<ul>
<li>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&#8217;s API,
<a class="reference internal" href="../c-api/init.html#PyEval_SetProfile" title="PyEval_SetProfile"><tt class="xref c c-func docutils literal">PyEval_SetProfile()</tt></a> and <a class="reference internal" href="../c-api/init.html#PyEval_SetTrace" title="PyEval_SetTrace"><tt class="xref c c-func docutils literal">PyEval_SetTrace()</tt></a>. The existing
<a class="reference internal" href="../library/sys.html#sys.setprofile" title="sys.setprofile"><tt class="xref py py-func docutils literal">sys.setprofile()</tt></a> and <a class="reference internal" href="../library/sys.html#sys.settrace" title="sys.settrace"><tt class="xref py py-func docutils literal">sys.settrace()</tt></a> functions still exist, and have
simply been changed to use the new C-level interface. (Contributed by Fred L.
Drake, Jr.)
</li>
<li>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#PyInterpreterState_Head" title="PyInterpreterState_Head"><tt class="xref c c-func docutils literal">PyInterpreterState_Head()</tt></a> and
<a class="reference internal" href="../c-api/init.html#PyInterpreterState_Next" title="PyInterpreterState_Next"><tt class="xref c c-func docutils literal">PyInterpreterState_Next()</tt></a> let a caller walk through all the existing
interpreter objects; <a class="reference internal" href="../c-api/init.html#PyInterpreterState_ThreadHead" title="PyInterpreterState_ThreadHead"><tt class="xref c c-func docutils literal">PyInterpreterState_ThreadHead()</tt></a> and
<a class="reference internal" href="../c-api/init.html#PyThreadState_Next" title="PyThreadState_Next"><tt class="xref c c-func docutils literal">PyThreadState_Next()</tt></a> allow looping over all the thread states for a given
interpreter. (Contributed by David Beazley.)
</li>
<li>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 not participate in garbage collection, so updating them
for 2.2 should be considered fairly high priority.
To upgrade an extension module to the new API, perform the following steps:
</li>
<li>Rename <tt class="xref c c-func docutils literal">Py_TPFLAGS_GC()</tt> to <tt class="xref c c-func docutils literal">PyTPFLAGS_HAVE_GC()</tt>.
</li>
<li><dl class="first docutils">
<dt>Use <a class="reference internal" href="../c-api/gcsupport.html#PyObject_GC_New" title="PyObject_GC_New"><tt class="xref c c-func docutils literal">PyObject_GC_New()</tt></a> or <a class="reference internal" href="../c-api/gcsupport.html#PyObject_GC_NewVar" title="PyObject_GC_NewVar"><tt class="xref c c-func docutils literal">PyObject_GC_NewVar()</tt></a> to allocate</dt>
<dd>objects, and <a class="reference internal" href="../c-api/gcsupport.html#PyObject_GC_Del" title="PyObject_GC_Del"><tt class="xref c c-func docutils literal">PyObject_GC_Del()</tt></a> to deallocate them.
</dd>
</dl>
</li>
<li><dl class="first docutils">
<dt>Rename <tt class="xref c c-func docutils literal">PyObject_GC_Init()</tt> to <a class="reference internal" href="../c-api/gcsupport.html#PyObject_GC_Track" title="PyObject_GC_Track"><tt class="xref c c-func docutils literal">PyObject_GC_Track()</tt></a> and</dt>
<dd><tt class="xref c c-func docutils literal">PyObject_GC_Fini()</tt> to <a class="reference internal" href="../c-api/gcsupport.html#PyObject_GC_UnTrack" title="PyObject_GC_UnTrack"><tt class="xref c c-func docutils literal">PyObject_GC_UnTrack()</tt></a>.
</dd>
</dl>
</li>
<li>Remove <tt class="xref c c-func docutils literal">PyGC_HEAD_SIZE()</tt> from object size calculations.
</li>
<li>Remove calls to <tt class="xref c c-func docutils literal">PyObject_AS_GC()</tt> and <tt class="xref c c-func docutils literal">PyObject_FROM_GC()</tt>.
</li>
<li>A new <tt class="docutils literal">et</tt> format sequence was added to <a class="reference internal" href="../c-api/arg.html#PyArg_ParseTuple" title="PyArg_ParseTuple"><tt class="xref c c-func docutils literal">PyArg_ParseTuple()</tt></a>; <tt class="docutils literal">et</tt>
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&#8217;s an 8-bit string, assuming it to already be in the desired
encoding. This differs from the <tt class="docutils literal">es</tt> format character, which assumes that
8-bit strings are in Python&#8217;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.)
</li>
<li>A different argument parsing function, <a class="reference internal" href="../c-api/arg.html#PyArg_UnpackTuple" title="PyArg_UnpackTuple"><tt class="xref c c-func docutils literal">PyArg_UnpackTuple()</tt></a>, has been
added that&#8217;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#PyObject" title="PyObject"><tt class="xref c c-type docutils literal">PyObject*</tt></a> variables that will be
filled in with argument values.
</li>
<li>Two new flags <a class="reference internal" href="../c-api/structures.html#METH_NOARGS" title="METH_NOARGS"><tt class="xref py py-const docutils literal">METH_NOARGS</tt></a> and <a class="reference internal" href="../c-api/structures.html#METH_O" title="METH_O"><tt class="xref py py-const docutils literal">METH_O</tt></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"><tt class="xref py py-const docutils literal">METH_VARARGS</tt></a>. Also, the old
<a class="reference internal" href="../c-api/structures.html#METH_OLDARGS" title="METH_OLDARGS"><tt class="xref py py-const docutils literal">METH_OLDARGS</tt></a> style of writing C methods is now officially deprecated.
</li>
<li>Two new wrapper functions, <a class="reference internal" href="../c-api/conversion.html#PyOS_snprintf" title="PyOS_snprintf"><tt class="xref c c-func docutils literal">PyOS_snprintf()</tt></a> and <a class="reference internal" href="../c-api/conversion.html#PyOS_vsnprintf" title="PyOS_vsnprintf"><tt class="xref c c-func docutils literal">PyOS_vsnprintf()</tt></a>
were added to provide cross-platform implementations for the relatively new
<tt class="xref c c-func docutils literal">snprintf()</tt> and <tt class="xref c c-func docutils literal">vsnprintf()</tt> C lib APIs. In contrast to the standard
<tt class="xref c c-func docutils literal">sprintf()</tt> and <tt class="xref c c-func docutils literal">vsprintf()</tt> functions, the Python versions check the
bounds of the buffer used to protect against buffer overruns. (Contributed by
M.-A. Lemburg.)
</li>
<li>The <a class="reference internal" href="../c-api/tuple.html#_PyTuple_Resize" title="_PyTuple_Resize"><tt class="xref c c-func docutils literal">_PyTuple_Resize()</tt></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.
</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>
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.
Some of the more notable changes are:
<ul>
<li>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.
The most significant change is the ability to build Python as a framework,
enabled by supplying the --enable-framework option to the configure
script when compiling Python. According to Jack Jansen, &#8220;This installs a self-
contained Python installation plus the OS X framework &#8220;glue&#8221; into
<tt class="file docutils literal">/Library/Frameworks/Python.framework</tt> (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.&#8221;
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&#8217;ve been
left commented out in <tt class="file docutils literal">setup.py</tt>. People who want to experiment with
these modules can uncomment them manually.
</li>
<li>Keyword arguments passed to built-in functions that don&#8217;t take them now cause a
<a class="reference internal" href="../library/exceptions.html#exceptions.TypeError" title="exceptions.TypeError"><tt class="xref py py-exc docutils literal">TypeError</tt></a> exception to be raised, with the message &#8220;function takes no
keyword arguments&#8221;.
</li>
<li>Weak references, added in Python 2.1 as an extension module, are now part of
the core because they&#8217;re used in the implementation of new-style classes. The
<a class="reference internal" href="../library/exceptions.html#exceptions.ReferenceError" title="exceptions.ReferenceError"><tt class="xref py py-exc docutils literal">ReferenceError</tt></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."><tt class="xref py py-mod docutils literal">weakref</tt></a>
module to become a built-in exception.
</li>
<li>A new script, <tt class="file docutils literal">Tools/scripts/cleanfuture.py</tt> by Tim Peters,
automatically removes obsolete <tt class="docutils literal">__future__</tt> statements from Python source
code.
</li>
<li>An additional flags argument has been added to the built-in function
<a class="reference internal" href="../library/functions.html#compile" title="compile"><tt class="xref py py-func docutils literal">compile()</tt></a>, so the behaviour of <tt class="docutils literal">__future__</tt> statements can now be
correctly observed in simulated shells, such as those presented by IDLE and
other development environments. This is described in <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0264">PEP 264</a>. (Contributed
by Michael Hudson.)
</li>
<li>The new license introduced with Python 1.6 wasn&#8217;t GPL-compatible. This is
fixed by some minor textual changes to the 2.2 license, so it&#8217;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&#8217;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.
</li>
<li>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&#8217;s choice of ASCII as the default
encoding turns out to be an annoyance. On Unix, the locale&#8217;s character set is
used if <tt class="xref py py-func docutils literal">locale.nl_langinfo(CODESET)()</tt> is available. (Windows support was
contributed by Mark Hammond with assistance from Marc-André Lemburg. Unix
support was added by Martin von Löwis.)
</li>
<li>Large file support is now enabled on Windows. (Contributed by Tim Peters.)
</li>
<li>The <tt class="file docutils literal">Tools/scripts/ftpmirror.py</tt> script now parses a <tt class="file docutils literal">.netrc</tt>
file, if you have one. (Contributed by Mike Romberg.)
</li>
<li>Some features of the object returned by the <a class="reference internal" href="../library/functions.html#xrange" title="xrange"><tt class="xref py py-func docutils literal">xrange()</tt></a> function are now
deprecated, and trigger warnings when they&#8217;re accessed; they&#8217;ll disappear in
Python 2.3. <a class="reference internal" href="../library/functions.html#xrange" title="xrange"><tt class="xref py py-class docutils literal">xrange</tt></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"><tt class="xref std std-keyword docutils literal">in</tt></a>
operator, but these features were rarely used and therefore buggy. The
<tt class="xref py py-meth docutils literal">tolist()</tt> method and the <tt class="xref py py-attr docutils literal">start</tt>, <tt class="xref py py-attr docutils literal">stop</tt>, and <tt class="xref py py-attr docutils literal">step</tt>
attributes are also being deprecated. At the C level, the fourth argument to
the <tt class="xref c c-func docutils literal">PyRange_New()</tt> function, <tt class="docutils literal">repeat</tt>, has also been deprecated.
</li>
<li>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.
</li>
<li>On Windows, Python can now be compiled with Borland C thanks to a number of
patches contributed by Stephen Hansen, though the result isn&#8217;t fully functional
yet. (But this is progress...)
</li>
<li>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.)
</li>
<li>Files ending in <tt class="docutils literal">.pyw</tt> can now be imported on Windows. <tt class="docutils literal">.pyw</tt> 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&#8217;re also usable as modules. (Implemented by David Bolen.)
</li>
<li>On platforms where Python uses the C <tt class="xref c c-func docutils literal">dlopen()</tt> function to load
extension modules, it&#8217;s now possible to set the flags used by <tt class="xref c c-func docutils literal">dlopen()</tt>
using the <a class="reference internal" href="../library/sys.html#sys.getdlopenflags" title="sys.getdlopenflags"><tt class="xref py py-func docutils literal">sys.getdlopenflags()</tt></a> and <a class="reference internal" href="../library/sys.html#sys.setdlopenflags" title="sys.setdlopenflags"><tt class="xref py py-func docutils literal">sys.setdlopenflags()</tt></a> functions.
(Contributed by Bram Stolk.)
</li>
<li>The <a class="reference internal" href="../library/functions.html#pow" title="pow"><tt class="xref py py-func docutils literal">pow()</tt></a> built-in function no longer supports 3 arguments when
floating-point numbers are supplied. <tt class="docutils literal">pow(x, y, z)</tt> returns <tt class="docutils literal">(x**y) % z</tt>,
but this is never useful for floating point numbers, and the final result varies
unpredictably depending on the platform. A call such as <tt class="docutils literal">pow(2.0, 8.0, 7.0)</tt>
will now raise a <a class="reference internal" href="../library/exceptions.html#exceptions.TypeError" title="exceptions.TypeError"><tt class="xref py py-exc docutils literal">TypeError</tt></a> exception.
</li>
</ul>
</div>
<div class="section" id="acknowledgements">
<h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Permalink to this headline">¶</a></h2>
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&#8217;Donnell, Joonas Paalasma, Tim Peters, Jens Quade, Tom
Reinhardt, Neil Schemenauer, Guido van Rossum, Greg Ward, Edward Welbourne.
</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&#8217;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>
 <a href="2.3.html"
 title="previous chapter">What&#8217;s New in Python 2.3</a>
 <h4>Next topic</h4>
 <a href="2.1.html"
 title="next chapter">What&#8217;s New in Python 2.1</a>
<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.2.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" />
 <input type="submit" value="Go" />
 <input type="hidden" name="check_keywords" value="yes" />
 <input type="hidden" name="area" value="default" />
 </form>
 
 Enter search terms or a module, class or function name.
 
</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.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="http://www.python.org/">Python</a> &raquo;</li>
 <li>
 <a href="../index.html">Python 2.7.5 documentation</a> &raquo;
 </li>

<li><a href="index.html" >What&#8217;s New in Python</a> &raquo;</li> 
 </ul>
 </div>
 <div class="footer">
 &copy; <a href="../copyright.html">Copyright</a> 1990-2020, Python Software Foundation.
 
 The Python Software Foundation is a non-profit corporation.
 <a href="http://www.python.org/psf/donations/">Please donate.</a>
 
 Last updated on Oct 13, 2020.
 <a href="../bugs.html">Found a bug</a>?
 
 Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3.
 </div>

</body>
</html>