Gecko [ nbspublicschool.com ]

Name	Size	Permission
2.0.html	121.13 KB	-rw-r--r--
2.1.html	74.86 KB	-rw-r--r--
2.2.html	129.31 KB	-rw-r--r--
2.3.html	214.29 KB	-rw-r--r--
2.4.html	155.06 KB	-rw-r--r--
2.5.html	231.71 KB	-rw-r--r--
2.6.html	329.35 KB	-rw-r--r--
2.7.html	276.15 KB	-rw-r--r--
index.html	24.76 KB	-rw-r--r--

Code Editor : 2.0.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.0 &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="The Python Tutorial" href="../tutorial/index.html" />
 <link rel="prev" title="What’s New in Python 2.1" href="2.1.html" />
 <link rel="shortcut icon" type="image/png" href="../_static/py.png" />
 <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="../tutorial/index.html" title="The Python Tutorial"
 accesskey="N">next</a> |</li>
 <li class="right" >
 <a href="2.1.html" title="What’s New in Python 2.1"
 accesskey="P">previous</a> |</li>
 <li><img src="../_static/py.png" alt=""
 style="vertical-align: middle; margin-top: -1px"/></li>
 <li><a href="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-0">
<h1>What&#8217;s New in Python 2.0<a class="headerlink" href="#what-s-new-in-python-2-0" 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 and Moshe Zadka</td>
</tr>
</tbody>
</table>
<div class="section" id="introduction">
<h2>Introduction<a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
A new release of Python, version 2.0, was released on October 16, 2000. This
article covers the exciting new features in 2.0, highlights some other useful
changes, and points out a few incompatible changes that may require rewriting
code.
Python&#8217;s development never completely stops between releases, and a steady flow
of bug fixes and improvements are always being submitted. A host of minor fixes,
a few optimizations, additional docstrings, and better error messages went into
2.0; to list them all would be impossible, but they&#8217;re certainly significant.
Consult the publicly-available CVS logs if you want to see the full list. This
progress is due to the five developers working for PythonLabs are now getting
paid to spend their days fixing bugs, and also due to the improved communication
resulting from moving to SourceForge.
</div>
<div class="section" id="what-about-python-1-6">
<h2>What About Python 1.6?<a class="headerlink" href="#what-about-python-1-6" title="Permalink to this headline">¶</a></h2>
Python 1.6 can be thought of as the Contractual Obligations Python release.
After the core development team left CNRI in May 2000, CNRI requested that a 1.6
release be created, containing all the work on Python that had been performed at
CNRI. Python 1.6 therefore represents the state of the CVS tree as of May 2000,
with the most significant new feature being Unicode support. Development
continued after May, of course, so the 1.6 tree received a few fixes to ensure
that it&#8217;s forward-compatible with Python 2.0. 1.6 is therefore part of Python&#8217;s
evolution, and not a side branch.
So, should you take much interest in Python 1.6? Probably not. The 1.6final
and 2.0beta1 releases were made on the same day (September 5, 2000), the plan
being to finalize Python 2.0 within a month or so. If you have applications to
maintain, there seems little point in breaking things by moving to 1.6, fixing
them, and then having another round of breakage within a month by moving to 2.0;
you&#8217;re better off just going straight to 2.0. Most of the really interesting
features described in this document are only in 2.0, because a lot of work was
done between May and September.
</div>
<div class="section" id="new-development-process">
<h2>New Development Process<a class="headerlink" href="#new-development-process" title="Permalink to this headline">¶</a></h2>
The most important change in Python 2.0 may not be to the code at all, but to
how Python is developed: in May 2000 the Python developers began using the tools
made available by SourceForge for storing source code, tracking bug reports,
and managing the queue of patch submissions. To report bugs or submit patches
for Python 2.0, use the bug tracking and patch manager tools available from
Python&#8217;s project page, located at <a class="reference external" href="http://sourceforge.net/projects/python/">http://sourceforge.net/projects/python/</a>.
The most important of the services now hosted at SourceForge is the Python CVS
tree, the version-controlled repository containing the source code for Python.
Previously, there were roughly 7 or so people who had write access to the CVS
tree, and all patches had to be inspected and checked in by one of the people on
this short list. Obviously, this wasn&#8217;t very scalable. By moving the CVS tree
to SourceForge, it became possible to grant write access to more people; as of
September 2000 there were 27 people able to check in changes, a fourfold
increase. This makes possible large-scale changes that wouldn&#8217;t be attempted if
they&#8217;d have to be filtered through the small group of core developers. For
example, one day Peter Schneider-Kamp took it into his head to drop K&amp;R C
compatibility and convert the C source for Python to ANSI C. After getting
approval on the python-dev mailing list, he launched into a flurry of checkins
that lasted about a week, other developers joined in to help, and the job was
done. If there were only 5 people with write access, probably that task would
have been viewed as &#8220;nice, but not worth the time and effort needed&#8221; and it
would never have gotten done.
The shift to using SourceForge&#8217;s services has resulted in a remarkable increase
in the speed of development. Patches now get submitted, commented on, revised
by people other than the original submitter, and bounced back and forth between
people until the patch is deemed worth checking in. Bugs are tracked in one
central location and can be assigned to a specific person for fixing, and we can
count the number of open bugs to measure progress. This didn&#8217;t come without a
cost: developers now have more e-mail to deal with, more mailing lists to
follow, and special tools had to be written for the new environment. For
example, SourceForge sends default patch and bug notification e-mail messages
that are completely unhelpful, so Ka-Ping Yee wrote an HTML screen-scraper that
sends more useful messages.
The ease of adding code caused a few initial growing pains, such as code was
checked in before it was ready or without getting clear agreement from the
developer group. The approval process that has emerged is somewhat similar to
that used by the Apache group. Developers can vote +1, +0, -0, or -1 on a patch;
+1 and -1 denote acceptance or rejection, while +0 and -0 mean the developer is
mostly indifferent to the change, though with a slight positive or negative
slant. The most significant change from the Apache model is that the voting is
essentially advisory, letting Guido van Rossum, who has Benevolent Dictator For
Life status, know what the general opinion is. He can still ignore the result of
a vote, and approve or reject a change even if the community disagrees with him.
Producing an actual patch is the last step in adding a new feature, and is
usually easy compared to the earlier task of coming up with a good design.
Discussions of new features can often explode into lengthy mailing list threads,
making the discussion hard to follow, and no one can read every posting to
python-dev. Therefore, a relatively formal process has been set up to write
Python Enhancement Proposals (PEPs), modelled on the Internet RFC process. PEPs
are draft documents that describe a proposed new feature, and are continually
revised until the community reaches a consensus, either accepting or rejecting
the proposal. Quoting from the introduction to PEP 1, &#8220;PEP Purpose and
Guidelines&#8221;:
<blockquote class="epigraph">
<div>PEP stands for Python Enhancement Proposal. A PEP is a design document
providing information to the Python community, or describing a new feature for
Python. The PEP should provide a concise technical specification of the feature
and a rationale for the feature.
We intend PEPs to be the primary mechanisms for proposing new features, for
collecting community input on an issue, and for documenting the design decisions
that have gone into Python. The PEP author is responsible for building
consensus within the community and documenting dissenting opinions.
</div></blockquote>
Read the rest of PEP 1 for the details of the PEP editorial process, style, and
format. PEPs are kept in the Python CVS tree on SourceForge, though they&#8217;re not
part of the Python 2.0 distribution, and are also available in HTML form from
<a class="reference external" href="http://www.python.org/peps/">http://www.python.org/peps/</a>. As of September 2000, there are 25 PEPS, ranging
from PEP 201, &#8220;Lockstep Iteration&#8221;, to PEP 225, &#8220;Elementwise/Objectwise
Operators&#8221;.
</div>
<div class="section" id="unicode">
<h2>Unicode<a class="headerlink" href="#unicode" title="Permalink to this headline">¶</a></h2>
The largest new feature in Python 2.0 is a new fundamental data type: Unicode
strings. Unicode uses 16-bit numbers to represent characters instead of the
8-bit number used by ASCII, meaning that 65,536 distinct characters can be
supported.
The final interface for Unicode support was arrived at through countless often-
stormy discussions on the python-dev mailing list, and mostly implemented by
Marc-André Lemburg, based on a Unicode string type implementation by Fredrik
Lundh. A detailed explanation of the interface was written up as <a class="pep reference external" href="http://www.python.org/dev/peps/pep-0100">PEP 100</a>,
&#8220;Python Unicode Integration&#8221;. This article will simply cover the most
significant points about the Unicode interfaces.
In Python source code, Unicode strings are written as <tt class="docutils literal">u&quot;string&quot;</tt>. Arbitrary
Unicode characters can be written using a new escape sequence, <tt class="docutils literal">\uHHHH</tt>, where
HHHH is a 4-digit hexadecimal number from 0000 to FFFF. The existing
<tt class="docutils literal">\xHHHH</tt> escape sequence can also be used, and octal escapes can be used for
characters up to U+01FF, which is represented by <tt class="docutils literal">\777</tt>.
Unicode strings, just like regular strings, are an immutable sequence type.
They can be indexed and sliced, but not modified in place. Unicode strings have
an <tt class="docutils literal">encode( [encoding] )</tt> method that returns an 8-bit string in the desired
encoding. Encodings are named by strings, such as <tt class="docutils literal">'ascii'</tt>, <tt class="docutils literal">'utf-8'</tt>,
<tt class="docutils literal">'iso-8859-1'</tt>, or whatever. A codec API is defined for implementing and
registering new encodings that are then available throughout a Python program.
If an encoding isn&#8217;t specified, the default encoding is usually 7-bit ASCII,
though it can be changed for your Python installation by calling the
<tt class="xref py py-func docutils literal">sys.setdefaultencoding(encoding)()</tt> function in a customised version of
<tt class="file docutils literal">site.py</tt>.
Combining 8-bit and Unicode strings always coerces to Unicode, using the default
ASCII encoding; the result of <tt class="docutils literal">'a' + u'bc'</tt> is <tt class="docutils literal">u'abc'</tt>.
New built-in functions have been added, and existing built-ins modified to
support Unicode:
<ul class="simple">
<li><tt class="docutils literal">unichr(ch)</tt> returns a Unicode string 1 character long, containing the
character ch.</li>
<li><tt class="docutils literal">ord(u)</tt>, where u is a 1-character regular or Unicode string, returns the
number of the character as an integer.</li>
<li><tt class="docutils literal">unicode(string [, encoding]&nbsp; [, errors] )</tt> creates a Unicode string
from an 8-bit string. <tt class="docutils literal">encoding</tt> is a string naming the encoding to use. The
<tt class="docutils literal">errors</tt> parameter specifies the treatment of characters that are invalid for
the current encoding; passing <tt class="docutils literal">'strict'</tt> as the value causes an exception to
be raised on any encoding error, while <tt class="docutils literal">'ignore'</tt> causes errors to be silently
ignored and <tt class="docutils literal">'replace'</tt> uses U+FFFD, the official replacement character, in
case of any problems.</li>
<li>The <a class="reference internal" href="../reference/simple_stmts.html#exec"><tt class="xref std std-keyword docutils literal">exec</tt></a> statement, and various built-ins such as <tt class="docutils literal">eval()</tt>,
<tt class="docutils literal">getattr()</tt>, and <tt class="docutils literal">setattr()</tt> will also accept Unicode strings as well as
regular strings. (It&#8217;s possible that the process of fixing this missed some
built-ins; if you find a built-in function that accepts strings but doesn&#8217;t
accept Unicode strings at all, please report it as a bug.)</li>
</ul>
A new module, <a class="reference internal" href="../library/unicodedata.html#module-unicodedata" title="unicodedata: Access the Unicode Database."><tt class="xref py py-mod docutils literal">unicodedata</tt></a>, provides an interface to Unicode character
properties. For example, <tt class="docutils literal">unicodedata.category(u'A')</tt> returns the 2-character
string &#8216;Lu&#8217;, the &#8216;L&#8217; denoting it&#8217;s a letter, and &#8216;u&#8217; meaning that it&#8217;s
uppercase. <tt class="docutils literal">unicodedata.bidirectional(u'\u0660')</tt> returns &#8216;AN&#8217;, meaning that
U+0660 is an Arabic number.
The <a class="reference internal" href="../library/codecs.html#module-codecs" title="codecs: Encode and decode data and streams."><tt class="xref py py-mod docutils literal">codecs</tt></a> module contains functions to look up existing encodings and
register new ones. Unless you want to implement a new encoding, you&#8217;ll most
often use the <tt class="xref py py-func docutils literal">codecs.lookup(encoding)()</tt> function, which returns a
4-element tuple: <tt class="docutils literal">(encode_func, decode_func, stream_reader, stream_writer)</tt>.
<ul class="simple">
<li>encode_func is a function that takes a Unicode string, and returns a 2-tuple
<tt class="docutils literal">(string, length)</tt>. string is an 8-bit string containing a portion (perhaps
all) of the Unicode string converted into the given encoding, and length tells
you how much of the Unicode string was converted.</li>
<li>decode_func is the opposite of encode_func, taking an 8-bit string and
returning a 2-tuple <tt class="docutils literal">(ustring, length)</tt>, consisting of the resulting Unicode
string ustring and the integer length telling how much of the 8-bit string
was consumed.</li>
<li>stream_reader is a class that supports decoding input from a stream.
stream_reader(file_obj) returns an object that supports the <tt class="xref py py-meth docutils literal">read()</tt>,
<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>, and <tt class="xref py py-meth docutils literal">readlines()</tt> methods. These methods will all
translate from the given encoding and return Unicode strings.</li>
<li>stream_writer, similarly, is a class that supports encoding output to a
stream. stream_writer(file_obj) returns an object that supports the
<tt class="xref py py-meth docutils literal">write()</tt> and <tt class="xref py py-meth docutils literal">writelines()</tt> methods. These methods expect Unicode
strings, translating them to the given encoding on output.</li>
</ul>
For example, the following code writes a Unicode string into a file, encoding
it as UTF-8:
<div class="highlight-python"><div class="highlight"><pre>import codecs

unistr = u&#39;\u0660\u2000ab ...&#39;

(UTF8_encode, UTF8_decode,
 UTF8_streamreader, UTF8_streamwriter) = codecs.lookup(&#39;UTF-8&#39;)

output = UTF8_streamwriter( open( &#39;/tmp/output&#39;, &#39;wb&#39;) )
output.write( unistr )
output.close()
</pre></div>
</div>
The following code would then read UTF-8 input from the file:
<div class="highlight-python"><div class="highlight"><pre>input = UTF8_streamreader( open( &#39;/tmp/output&#39;, &#39;rb&#39;) )
print repr(input.read())
input.close()
</pre></div>
</div>
Unicode-aware regular expressions are available through 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,
which has a new underlying implementation called SRE written by Fredrik Lundh of
Secret Labs AB.
A <tt class="docutils literal">-U</tt> command line option was added which causes the Python compiler to
interpret all string literals as Unicode string literals. This is intended to be
used in testing and future-proofing your Python code, since some future version
of Python may drop support for 8-bit strings and provide only Unicode strings.
</div>
<div class="section" id="list-comprehensions">
<h2>List Comprehensions<a class="headerlink" href="#list-comprehensions" title="Permalink to this headline">¶</a></h2>
Lists are a workhorse data type in Python, and many programs manipulate a list
at some point. Two common operations on lists are to loop over them, and either
pick out the elements that meet a certain criterion, or apply some function to
each element. For example, given a list of strings, you might want to pull out
all the strings containing a given substring, or strip off trailing whitespace
from each line.
The existing <a class="reference internal" href="../library/functions.html#map" title="map"><tt class="xref py py-func docutils literal">map()</tt></a> and <a class="reference internal" href="../library/functions.html#filter" title="filter"><tt class="xref py py-func docutils literal">filter()</tt></a> functions can be used for this
purpose, but they require a function as one of their arguments. This is fine if
there&#8217;s an existing built-in function that can be passed directly, but if there
isn&#8217;t, you have to create a little function to do the required work, and
Python&#8217;s scoping rules make the result ugly if the little function needs
additional information. Take the first example in the previous paragraph,
finding all the strings in the list containing a given substring. You could
write the following to do it:
<div class="highlight-python"><div class="highlight"><pre># Given the list L, make a list of all strings
# containing the substring S.
sublist = filter( lambda s, substring=S:
 string.find(s, substring) != -1,
 L)
</pre></div>
</div>
Because of Python&#8217;s scoping rules, a default argument is used so that the
anonymous function created by the <a class="reference internal" href="../reference/expressions.html#lambda"><tt class="xref std std-keyword docutils literal">lambda</tt></a> statement knows what
substring is being searched for. List comprehensions make this cleaner:
<div class="highlight-python"><div class="highlight"><pre>sublist = [ s for s in L if string.find(s, S) != -1 ]
</pre></div>
</div>
List comprehensions have the form:
<div class="highlight-python"><pre>[ expression for expr in sequence1
 for expr2 in sequence2 ...
 for exprN in sequenceN
 if condition ]</pre>
</div>
The <a class="reference internal" href="../reference/compound_stmts.html#for"><tt class="xref std std-keyword docutils literal">for</tt></a>...<a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a> clauses contain the sequences to be
iterated over. The sequences do not have to be the same length, because they
are not iterated over in parallel, but from left to right; this is explained
more clearly in the following paragraphs. The elements of the generated list
will be the successive values of expression. The final <a class="reference internal" href="../reference/compound_stmts.html#if"><tt class="xref std std-keyword docutils literal">if</tt></a> clause
is optional; if present, expression is only evaluated and added to the result
if condition is true.
To make the semantics very clear, a list comprehension is equivalent to the
following Python code:
<div class="highlight-python"><pre>for expr1 in sequence1:
 for expr2 in sequence2:
 ...
 for exprN in sequenceN:
 if (condition):
 # Append the value of
 # the expression to the
 # resulting list.</pre>
</div>
This means that when there are multiple <a class="reference internal" href="../reference/compound_stmts.html#for"><tt class="xref std std-keyword docutils literal">for</tt></a>...<a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a>
clauses, the resulting list will be equal to the product of the lengths of all
the sequences. If you have two lists of length 3, the output list is 9 elements
long:
<div class="highlight-python"><pre>seq1 = 'abc'
seq2 = (1,2,3)
&gt;&gt;&gt; [ (x,y) for x in seq1 for y in seq2]
[('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1),
('c', 2), ('c', 3)]</pre>
</div>
To avoid introducing an ambiguity into Python&#8217;s grammar, if expression is
creating a tuple, it must be surrounded with parentheses. The first list
comprehension below is a syntax error, while the second one is correct:
<div class="highlight-python"><pre># Syntax error
[ x,y for x in seq1 for y in seq2]
# Correct
[ (x,y) for x in seq1 for y in seq2]</pre>
</div>
The idea of list comprehensions originally comes from the functional programming
language Haskell (<a class="reference external" href="http://www.haskell.org">http://www.haskell.org</a>). Greg Ewing argued most effectively
for adding them to Python and wrote the initial list comprehension patch, which
was then discussed for a seemingly endless time on the python-dev mailing list
and kept up-to-date by Skip Montanaro.
</div>
<div class="section" id="augmented-assignment">
<h2>Augmented Assignment<a class="headerlink" href="#augmented-assignment" title="Permalink to this headline">¶</a></h2>
Augmented assignment operators, another long-requested feature, have been added
to Python 2.0. Augmented assignment operators include <tt class="docutils literal">+=</tt>, <tt class="docutils literal">-=</tt>, <tt class="docutils literal">*=</tt>,
and so forth. For example, the statement <tt class="docutils literal">a += 2</tt> increments the value of the
variable <tt class="docutils literal">a</tt> by 2, equivalent to the slightly lengthier <tt class="docutils literal">a = a + 2</tt>.
The full list of supported assignment operators is <tt class="docutils literal">+=</tt>, <tt class="docutils literal">-=</tt>, <tt class="docutils literal">*=</tt>,
<tt class="docutils literal">/=</tt>, <tt class="docutils literal">%=</tt>, <tt class="docutils literal">**=</tt>, <tt class="docutils literal">&amp;=</tt>, <tt class="docutils literal">|=</tt>, <tt class="docutils literal">^=</tt>, <tt class="docutils literal">&gt;&gt;=</tt>, and <tt class="docutils literal">&lt;&lt;=</tt>. Python
classes can override the augmented assignment operators by defining methods
named <a class="reference internal" href="../reference/datamodel.html#object.__iadd__" title="object.__iadd__"><tt class="xref py py-meth docutils literal">__iadd__()</tt></a>, <a class="reference internal" href="../reference/datamodel.html#object.__isub__" title="object.__isub__"><tt class="xref py py-meth docutils literal">__isub__()</tt></a>, etc. For example, the following
<tt class="xref py py-class docutils literal">Number</tt> class stores a number and supports using += to create a new
instance with an incremented value.
<div class="highlight-python"><div class="highlight"><pre>class Number:
 def __init__(self, value):
 self.value = value
 def __iadd__(self, increment):
 return Number( self.value + increment)

n = Number(5)
n += 3
print n.value
</pre></div>
</div>
The <a class="reference internal" href="../reference/datamodel.html#object.__iadd__" title="object.__iadd__"><tt class="xref py py-meth docutils literal">__iadd__()</tt></a> special method is called with the value of the increment,
and should return a new instance with an appropriately modified value; this
return value is bound as the new value of the variable on the left-hand side.
Augmented assignment operators were first introduced in the C programming
language, and most C-derived languages, such as awk, C++, Java, Perl,
and PHP also support them. The augmented assignment patch was implemented by
Thomas Wouters.
</div>
<div class="section" id="string-methods">
<h2>String Methods<a class="headerlink" href="#string-methods" title="Permalink to this headline">¶</a></h2>
Until now string-manipulation functionality was in 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,
which was usually a front-end for the <tt class="xref py py-mod docutils literal">strop</tt> module written in C. The
addition of Unicode posed a difficulty for the <tt class="xref py py-mod docutils literal">strop</tt> module, because the
functions would all need to be rewritten in order to accept either 8-bit or
Unicode strings. For functions such as <a class="reference internal" href="../library/string.html#string.replace" title="string.replace"><tt class="xref py py-func docutils literal">string.replace()</tt></a>, which takes 3
string arguments, that means eight possible permutations, and correspondingly
complicated code.
Instead, Python 2.0 pushes the problem onto the string type, making string
manipulation functionality available through methods on both 8-bit strings and
Unicode strings.
<div class="highlight-python"><div class="highlight"><pre>&gt;&gt;&gt; &#39;andrew&#39;.capitalize()
&#39;Andrew&#39;
&gt;&gt;&gt; &#39;hostname&#39;.replace(&#39;os&#39;, &#39;linux&#39;)
&#39;hlinuxtname&#39;
&gt;&gt;&gt; &#39;moshe&#39;.find(&#39;sh&#39;)
2
</pre></div>
</div>
One thing that hasn&#8217;t changed, a noteworthy April Fools&#8217; joke notwithstanding,
is that Python strings are immutable. Thus, the string methods return new
strings, and do not modify the string on which they operate.
The old <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 is still around for backwards compatibility, but it
mostly acts as a front-end to the new string methods.
Two methods which have no parallel in pre-2.0 versions, although they did exist
in JPython for quite some time, are <tt class="xref py py-meth docutils literal">startswith()</tt> and <tt class="xref py py-meth docutils literal">endswith()</tt>.
<tt class="docutils literal">s.startswith(t)</tt> is equivalent to <tt class="docutils literal">s[:len(t)] == t</tt>, while
<tt class="docutils literal">s.endswith(t)</tt> is equivalent to <tt class="docutils literal">s[-len(t):] == t</tt>.
One other method which deserves special mention is <tt class="xref py py-meth docutils literal">join()</tt>. The
<tt class="xref py py-meth docutils literal">join()</tt> method of a string receives one parameter, a sequence of strings,
and is equivalent to the <a class="reference internal" href="../library/string.html#string.join" title="string.join"><tt class="xref py py-func docutils literal">string.join()</tt></a> function from the old <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, with the arguments reversed. In other words, <tt class="docutils literal">s.join(seq)</tt> is
equivalent to the old <tt class="docutils literal">string.join(seq, s)</tt>.
</div>
<div class="section" id="garbage-collection-of-cycles">
<h2>Garbage Collection of Cycles<a class="headerlink" href="#garbage-collection-of-cycles" title="Permalink to this headline">¶</a></h2>
The C implementation of Python uses reference counting to implement garbage
collection. Every Python object maintains a count of the number of references
pointing to itself, and adjusts the count as references are created or
destroyed. Once the reference count reaches zero, the object is no longer
accessible, since you need to have a reference to an object to access it, and if
the count is zero, no references exist any longer.
Reference counting has some pleasant properties: it&#8217;s easy to understand and
implement, and the resulting implementation is portable, fairly fast, and reacts
well with other libraries that implement their own memory handling schemes. The
major problem with reference counting is that it sometimes doesn&#8217;t realise that
objects are no longer accessible, resulting in a memory leak. This happens when
there are cycles of references.
Consider the simplest possible cycle, a class instance which has a reference to
itself:
<div class="highlight-python"><div class="highlight"><pre>instance = SomeClass()
instance.myself = instance
</pre></div>
</div>
After the above two lines of code have been executed, the reference count of
<tt class="docutils literal">instance</tt> is 2; one reference is from the variable named <tt class="docutils literal">'instance'</tt>, and
the other is from the <tt class="docutils literal">myself</tt> attribute of the instance.
If the next line of code is <tt class="docutils literal">del instance</tt>, what happens? The reference count
of <tt class="docutils literal">instance</tt> is decreased by 1, so it has a reference count of 1; the
reference in the <tt class="docutils literal">myself</tt> attribute still exists. Yet the instance is no
longer accessible through Python code, and it could be deleted. Several objects
can participate in a cycle if they have references to each other, causing all of
the objects to be leaked.
Python 2.0 fixes this problem by periodically executing a cycle detection
algorithm which looks for inaccessible cycles and deletes the objects involved.
A new <a class="reference internal" href="../library/gc.html#module-gc" title="gc: Interface to the cycle-detecting garbage collector."><tt class="xref py py-mod docutils literal">gc</tt></a> module provides functions to perform a garbage collection,
obtain debugging statistics, and tuning the collector&#8217;s parameters.
Running the cycle detection algorithm takes some time, and therefore will result
in some additional overhead. It is hoped that after we&#8217;ve gotten experience
with the cycle collection from using 2.0, Python 2.1 will be able to minimize
the overhead with careful tuning. It&#8217;s not yet obvious how much performance is
lost, because benchmarking this is tricky and depends crucially on how often the
program creates and destroys objects. The detection of cycles can be disabled
when Python is compiled, if you can&#8217;t afford even a tiny speed penalty or
suspect that the cycle collection is buggy, by specifying the
--without-cycle-gc switch when running the configure
script.
Several people tackled this problem and contributed to a solution. An early
implementation of the cycle detection approach was written by Toby Kelsey. The
current algorithm was suggested by Eric Tiedemann during a visit to CNRI, and
Guido van Rossum and Neil Schemenauer wrote two different implementations, which
were later integrated by Neil. Lots of other people offered suggestions along
the way; the March 2000 archives of the python-dev mailing list contain most of
the relevant discussion, especially in the threads titled &#8220;Reference cycle
collection for Python&#8221; and &#8220;Finalization again&#8221;.
</div>
<div class="section" id="other-core-changes">
<h2>Other Core Changes<a class="headerlink" href="#other-core-changes" title="Permalink to this headline">¶</a></h2>
Various minor changes have been made to Python&#8217;s syntax and built-in functions.
None of the changes are very far-reaching, but they&#8217;re handy conveniences.
<div class="section" id="minor-language-changes">
<h3>Minor Language Changes<a class="headerlink" href="#minor-language-changes" title="Permalink to this headline">¶</a></h3>
A new syntax makes it more convenient to call a given function with a tuple of
arguments and/or a dictionary of keyword arguments. In Python 1.5 and earlier,
you&#8217;d use the <a class="reference internal" href="../library/functions.html#apply" title="apply"><tt class="xref py py-func docutils literal">apply()</tt></a> built-in function: <tt class="docutils literal">apply(f, args, kw)</tt> calls the
function <tt class="xref py py-func docutils literal">f()</tt> with the argument tuple args and the keyword arguments in
the dictionary kw. <a class="reference internal" href="../library/functions.html#apply" title="apply"><tt class="xref py py-func docutils literal">apply()</tt></a> is the same in 2.0, but thanks to a patch
from Greg Ewing, <tt class="docutils literal">f(*args, **kw)</tt> as a shorter and clearer way to achieve the
same effect. This syntax is symmetrical with the syntax for defining
functions:
<div class="highlight-python"><div class="highlight"><pre>def f(*args, **kw):
 # args is a tuple of positional args,
 # kw is a dictionary of keyword args
 ...
</pre></div>
</div>
The <a class="reference internal" href="../reference/simple_stmts.html#print"><tt class="xref std std-keyword docutils literal">print</tt></a> statement can now have its output directed to a file-like
object by following the <a class="reference internal" href="../reference/simple_stmts.html#print"><tt class="xref std std-keyword docutils literal">print</tt></a> with <tt class="docutils literal">&gt;&gt; file</tt>, similar to the
redirection operator in Unix shells. Previously you&#8217;d either have to use the
<tt class="xref py py-meth docutils literal">write()</tt> method of the file-like object, which lacks the convenience and
simplicity of <a class="reference internal" href="../reference/simple_stmts.html#print"><tt class="xref std std-keyword docutils literal">print</tt></a>, or you could assign a new value to
<tt class="docutils literal">sys.stdout</tt> and then restore the old value. For sending output to standard
error, it&#8217;s much easier to write this:
<div class="highlight-python"><div class="highlight"><pre>print &gt;&gt; sys.stderr, &quot;Warning: action field not supplied&quot;
</pre></div>
</div>
Modules can now be renamed on importing them, using the syntax <tt class="docutils literal">import module
as name</tt> or <tt class="docutils literal">from module import name as othername</tt>. The patch was submitted
by Thomas Wouters.
A new format style is available when using the <tt class="docutils literal">%</tt> operator; &#8216;%r&#8217; will insert
the <a class="reference internal" href="../library/repr.html#module-repr" title="repr: Alternate repr() implementation with size limits."><tt class="xref py py-func docutils literal">repr()</tt></a> of its argument. This was also added from symmetry
considerations, this time for symmetry with the existing &#8216;%s&#8217; format style,
which inserts the <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a> of its argument. For example, <tt class="docutils literal">'%r %s' % ('abc',
'abc')</tt> returns a string containing <tt class="docutils literal">'abc' abc</tt>.
Previously there was no way to implement a class that overrode Python&#8217;s built-in
<a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a> operator and implemented a custom version. <tt class="docutils literal">obj in seq</tt> returns
true if obj is present in the sequence seq; Python computes this by simply
trying every index of the sequence until either obj is found or an
<a class="reference internal" href="../library/exceptions.html#exceptions.IndexError" title="exceptions.IndexError"><tt class="xref py py-exc docutils literal">IndexError</tt></a> is encountered. Moshe Zadka contributed a patch which adds a
<a class="reference internal" href="../reference/datamodel.html#object.__contains__" title="object.__contains__"><tt class="xref py py-meth docutils literal">__contains__()</tt></a> magic method for providing a custom implementation for
<a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a>. Additionally, new built-in objects written in C can define what
<a class="reference internal" href="../reference/expressions.html#in"><tt class="xref std std-keyword docutils literal">in</tt></a> means for them via a new slot in the sequence protocol.
Earlier versions of Python used a recursive algorithm for deleting objects.
Deeply nested data structures could cause the interpreter to fill up the C stack
and crash; Christian Tismer rewrote the deletion logic to fix this problem. On
a related note, comparing recursive objects recursed infinitely and crashed;
Jeremy Hylton rewrote the code to no longer crash, producing a useful result
instead. For example, after this code:
<div class="highlight-python"><div class="highlight"><pre>a = []
b = []
a.append(a)
b.append(b)
</pre></div>
</div>
The comparison <tt class="docutils literal">a==b</tt> returns true, because the two recursive data structures
are isomorphic. See the thread &#8220;trashcan and PR#7&#8221; in the April 2000 archives of
the python-dev mailing list for the discussion leading up to this
implementation, and some useful relevant links. Note that comparisons can now
also raise exceptions. In earlier versions of Python, a comparison operation
such as <tt class="docutils literal">cmp(a,b)</tt> would always produce an answer, even if a user-defined
<a class="reference internal" href="../reference/datamodel.html#object.__cmp__" title="object.__cmp__"><tt class="xref py py-meth docutils literal">__cmp__()</tt></a> method encountered an error, since the resulting exception would
simply be silently swallowed.
Work has been done on porting Python to 64-bit Windows on the Itanium processor,
mostly by Trent Mick of ActiveState. (Confusingly, <tt class="docutils literal">sys.platform</tt> is still
<tt class="docutils literal">'win32'</tt> on Win64 because it seems that for ease of porting, MS Visual C++
treats code as 32 bit on Itanium.) PythonWin also supports Windows CE; see the
Python CE page at <a class="reference external" href="http://pythonce.sourceforge.net/">http://pythonce.sourceforge.net/</a> for more information.
Another new platform is Darwin/MacOS X; initial support for it is in Python 2.0.
Dynamic loading works, if you specify &#8220;configure &#8211;with-dyld &#8211;with-suffix=.x&#8221;.
Consult the README in the Python source distribution for more instructions.
An attempt has been made to alleviate one of Python&#8217;s warts, the often-confusing
<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 when code refers to a local variable before the
variable has been assigned a value. For example, the following code raises an
exception on the <a class="reference internal" href="../reference/simple_stmts.html#print"><tt class="xref std std-keyword docutils literal">print</tt></a> statement in both 1.5.2 and 2.0; in 1.5.2 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 is raised, while 2.0 raises a new
<a class="reference internal" href="../library/exceptions.html#exceptions.UnboundLocalError" title="exceptions.UnboundLocalError"><tt class="xref py py-exc docutils literal">UnboundLocalError</tt></a> exception. <a class="reference internal" href="../library/exceptions.html#exceptions.UnboundLocalError" title="exceptions.UnboundLocalError"><tt class="xref py py-exc docutils literal">UnboundLocalError</tt></a> is a subclass of
<a class="reference internal" href="../library/exceptions.html#exceptions.NameError" title="exceptions.NameError"><tt class="xref py py-exc docutils literal">NameError</tt></a>, so any existing code that expects <a class="reference internal" href="../library/exceptions.html#exceptions.NameError" title="exceptions.NameError"><tt class="xref py py-exc docutils literal">NameError</tt></a> to be
raised should still work.
<div class="highlight-python"><div class="highlight"><pre>def f():
 print &quot;i=&quot;,i
 i = i + 1
f()
</pre></div>
</div>
Two new exceptions, <a class="reference internal" href="../library/exceptions.html#exceptions.TabError" title="exceptions.TabError"><tt class="xref py py-exc docutils literal">TabError</tt></a> and <a class="reference internal" href="../library/exceptions.html#exceptions.IndentationError" title="exceptions.IndentationError"><tt class="xref py py-exc docutils literal">IndentationError</tt></a>, have been
introduced. They&#8217;re both subclasses of <a class="reference internal" href="../library/exceptions.html#exceptions.SyntaxError" title="exceptions.SyntaxError"><tt class="xref py py-exc docutils literal">SyntaxError</tt></a>, and are raised when
Python code is found to be improperly indented.
</div>
<div class="section" id="changes-to-built-in-functions">
<h3>Changes to Built-in Functions<a class="headerlink" href="#changes-to-built-in-functions" title="Permalink to this headline">¶</a></h3>
A new built-in, <tt class="xref py py-func docutils literal">zip(seq1, seq2, ...)()</tt>, has been added. <a class="reference internal" href="../library/functions.html#zip" title="zip"><tt class="xref py py-func docutils literal">zip()</tt></a>
returns a list of tuples where each tuple contains the i-th element from each of
the argument sequences. The difference between <a class="reference internal" href="../library/functions.html#zip" title="zip"><tt class="xref py py-func docutils literal">zip()</tt></a> and <tt class="docutils literal">map(None,
seq1, seq2)</tt> is that <a class="reference internal" href="../library/functions.html#map" title="map"><tt class="xref py py-func docutils literal">map()</tt></a> pads the sequences with <tt class="docutils literal">None</tt> if the
sequences aren&#8217;t all of the same length, while <a class="reference internal" href="../library/functions.html#zip" title="zip"><tt class="xref py py-func docutils literal">zip()</tt></a> truncates the
returned list to the length of the shortest argument sequence.
The <a class="reference internal" href="../library/functions.html#int" title="int"><tt class="xref py py-func docutils literal">int()</tt></a> and <a class="reference internal" href="../library/functions.html#long" title="long"><tt class="xref py py-func docutils literal">long()</tt></a> functions now accept an optional &#8220;base&#8221;
parameter when the first argument is a string. <tt class="docutils literal">int('123', 10)</tt> returns 123,
while <tt class="docutils literal">int('123', 16)</tt> returns 291. <tt class="docutils literal">int(123, 16)</tt> raises 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 &#8220;can&#8217;t convert non-string with
explicit base&#8221;.
A new variable holding more detailed version information has been added to the
<a class="reference internal" href="../library/sys.html#module-sys" title="sys: Access system-specific parameters and functions."><tt class="xref py py-mod docutils literal">sys</tt></a> module. <tt class="docutils literal">sys.version_info</tt> is a tuple <tt class="docutils literal">(major, minor, micro,
level, serial)</tt> For example, in a hypothetical 2.0.1beta1, <tt class="docutils literal">sys.version_info</tt>
would be <tt class="docutils literal">(2, 0, 1, 'beta', 1)</tt>. level is a string such as <tt class="docutils literal">&quot;alpha&quot;</tt>,
<tt class="docutils literal">&quot;beta&quot;</tt>, or <tt class="docutils literal">&quot;final&quot;</tt> for a final release.
Dictionaries have an odd new method, <tt class="xref py py-meth docutils literal">setdefault(key, default)()</tt>, which
behaves similarly to the existing <tt class="xref py py-meth docutils literal">get()</tt> method. However, if the key is
missing, <tt class="xref py py-meth docutils literal">setdefault()</tt> both returns the value of default as <tt class="xref py py-meth docutils literal">get()</tt>
would do, and also inserts it into the dictionary as the value for key. Thus,
the following lines of code:
<div class="highlight-python"><div class="highlight"><pre>if dict.has_key( key ): return dict[key]
else:
 dict[key] = []
 return dict[key]
</pre></div>
</div>
can be reduced to a single <tt class="docutils literal">return dict.setdefault(key, [])</tt> statement.
The interpreter sets a maximum recursion depth in order to catch runaway
recursion before filling the C stack and causing a core dump or GPF..
Previously this limit was fixed when you compiled Python, but in 2.0 the maximum
recursion depth can be read and modified using <a class="reference internal" href="../library/sys.html#sys.getrecursionlimit" title="sys.getrecursionlimit"><tt class="xref py py-func docutils literal">sys.getrecursionlimit()</tt></a> and
<a class="reference internal" href="../library/sys.html#sys.setrecursionlimit" title="sys.setrecursionlimit"><tt class="xref py py-func docutils literal">sys.setrecursionlimit()</tt></a>. The default value is 1000, and a rough maximum
value for a given platform can be found by running a new script,
<tt class="file docutils literal">Misc/find_recursionlimit.py</tt>.
</div>
</div>
<div class="section" id="porting-to-2-0">
<h2>Porting to 2.0<a class="headerlink" href="#porting-to-2-0" title="Permalink to this headline">¶</a></h2>
New Python releases try hard to be compatible with previous releases, and the
record has been pretty good. However, some changes are considered useful
enough, usually because they fix initial design decisions that turned out to be
actively mistaken, that breaking backward compatibility can&#8217;t always be avoided.
This section lists the changes in Python 2.0 that may cause old Python code to
break.
The change which will probably break the most code is tightening up the
arguments accepted by some methods. Some methods would take multiple arguments
and treat them as a tuple, particularly various list methods such as
<tt class="xref py py-meth docutils literal">append()</tt> and <tt class="xref py py-meth docutils literal">insert()</tt>. In earlier versions of Python, if <tt class="docutils literal">L</tt> is
a list, <tt class="docutils literal">L.append( 1,2 )</tt> appends the tuple <tt class="docutils literal">(1,2)</tt> to the list. In Python
2.0 this causes 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:
&#8216;append requires exactly 1 argument; 2 given&#8217;. The fix is to simply add an
extra set of parentheses to pass both values as a tuple: <tt class="docutils literal">L.append( (1,2) )</tt>.
The earlier versions of these methods were more forgiving because they used an
old function in Python&#8217;s C interface to parse their arguments; 2.0 modernizes
them to use <tt class="xref py py-func docutils literal">PyArg_ParseTuple()</tt>, the current argument parsing function,
which provides more helpful error messages and treats multi-argument calls as
errors. If you absolutely must use 2.0 but can&#8217;t fix your code, you can edit
<tt class="file docutils literal">Objects/listobject.c</tt> and define the preprocessor symbol
<tt class="docutils literal">NO_STRICT_LIST_APPEND</tt> to preserve the old behaviour; this isn&#8217;t recommended.
Some of the functions in 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 are still forgiving in this
way. For example, <tt class="xref py py-func docutils literal">socket.connect( ('hostname', 25) )()</tt> is the correct
form, passing a tuple representing an IP address, but <tt class="xref py py-func docutils literal">socket.connect(
'hostname', 25 )()</tt> also works. <tt class="xref py py-func docutils literal">socket.connect_ex()</tt> and <tt class="xref py py-func docutils literal">socket.bind()</tt>
are similarly easy-going. 2.0alpha1 tightened these functions up, but because
the documentation actually used the erroneous multiple argument form, many
people wrote code which would break with the stricter checking. GvR backed out
the changes in the face of public reaction, so for the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><tt class="xref py py-mod docutils literal">socket</tt></a> module, the
documentation was fixed and the multiple argument form is simply marked as
deprecated; it will be tightened up again in a future Python version.
The <tt class="docutils literal">\x</tt> escape in string literals now takes exactly 2 hex digits. Previously
it would consume all the hex digits following the &#8216;x&#8217; and take the lowest 8 bits
of the result, so <tt class="docutils literal">\x123456</tt> was equivalent to <tt class="docutils literal">\x56</tt>.
The <a class="reference internal" href="../library/exceptions.html#exceptions.AttributeError" title="exceptions.AttributeError"><tt class="xref py py-exc docutils literal">AttributeError</tt></a> and <a class="reference internal" href="../library/exceptions.html#exceptions.NameError" title="exceptions.NameError"><tt class="xref py py-exc docutils literal">NameError</tt></a> exceptions have a more friendly
error message, whose text will be something like <tt class="docutils literal">'Spam' instance has no
attribute 'eggs'</tt> or <tt class="docutils literal">name 'eggs' is not defined</tt>. Previously the error
message was just the missing attribute name <tt class="docutils literal">eggs</tt>, and code written to take
advantage of this fact will break in 2.0.
Some work has been done to make integers and long integers a bit more
interchangeable. In 1.5.2, large-file support was added for Solaris, to allow
reading files larger than 2 GiB; this made the <tt class="xref py py-meth docutils literal">tell()</tt> method of file
objects return a long integer instead of a regular integer. Some code would
subtract two file offsets and attempt to use the result to multiply a sequence
or slice a string, but this raised a <a class="reference internal" href="../library/exceptions.html#exceptions.TypeError" title="exceptions.TypeError"><tt class="xref py py-exc docutils literal">TypeError</tt></a>. In 2.0, long integers
can be used to multiply or slice a sequence, and it&#8217;ll behave as you&#8217;d
intuitively expect it to; <tt class="docutils literal">3L * 'abc'</tt> produces &#8216;abcabcabc&#8217;, and
<tt class="docutils literal">(0,1,2,3)[2L:4L]</tt> produces (2,3). Long integers can also be used in various
contexts where previously only integers were accepted, such as in the
<tt class="xref py py-meth docutils literal">seek()</tt> method of file objects, and in the formats supported by the <tt class="docutils literal">%</tt>
operator (<tt class="docutils literal">%d</tt>, <tt class="docutils literal">%i</tt>, <tt class="docutils literal">%x</tt>, etc.). For example, <tt class="docutils literal">&quot;%d&quot; % 2L**64</tt> will
produce the string <tt class="docutils literal">18446744073709551616</tt>.
The subtlest long integer change of all is that the <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a> of a long
integer no longer has a trailing &#8216;L&#8217; character, though <a class="reference internal" href="../library/repr.html#module-repr" title="repr: Alternate repr() implementation with size limits."><tt class="xref py py-func docutils literal">repr()</tt></a> still
includes it. The &#8216;L&#8217; annoyed many people who wanted to print long integers that
looked just like regular integers, since they had to go out of their way to chop
off the character. This is no longer a problem in 2.0, but code which does
<tt class="docutils literal">str(longval)[:-1]</tt> and assumes the &#8216;L&#8217; is there, will now lose the final
digit.
Taking the <a class="reference internal" href="../library/repr.html#module-repr" title="repr: Alternate repr() implementation with size limits."><tt class="xref py py-func docutils literal">repr()</tt></a> of a float now uses a different formatting precision
than <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a>. <a class="reference internal" href="../library/repr.html#module-repr" title="repr: Alternate repr() implementation with size limits."><tt class="xref py py-func docutils literal">repr()</tt></a> uses <tt class="docutils literal">%.17g</tt> format string for C&#8217;s
<tt class="xref py py-func docutils literal">sprintf()</tt>, while <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a> uses <tt class="docutils literal">%.12g</tt> as before. The effect is that
<a class="reference internal" href="../library/repr.html#module-repr" title="repr: Alternate repr() implementation with size limits."><tt class="xref py py-func docutils literal">repr()</tt></a> may occasionally show more decimal places than <a class="reference internal" href="../library/functions.html#str" title="str"><tt class="xref py py-func docutils literal">str()</tt></a>, for
certain numbers. For example, the number 8.1 can&#8217;t be represented exactly in
binary, so <tt class="docutils literal">repr(8.1)</tt> is <tt class="docutils literal">'8.0999999999999996'</tt>, while str(8.1) is
<tt class="docutils literal">'8.1'</tt>.
The <tt class="docutils literal">-X</tt> command-line option, which turned all standard exceptions into
strings instead of classes, has been removed; the standard exceptions will now
always be classes. The <a class="reference internal" href="../library/exceptions.html#module-exceptions" title="exceptions: Standard exception classes."><tt class="xref py py-mod docutils literal">exceptions</tt></a> module containing the standard
exceptions was translated from Python to a built-in C module, written by Barry
Warsaw and Fredrik Lundh.
</div>
<div class="section" id="extending-embedding-changes">
<h2>Extending/Embedding Changes<a class="headerlink" href="#extending-embedding-changes" title="Permalink to this headline">¶</a></h2>
Some of the changes are under the covers, and will only be apparent to people
writing C extension modules or embedding a Python interpreter in a larger
application. If you aren&#8217;t dealing with Python&#8217;s C API, you can safely skip
this section.
The version number of the Python C API was incremented, so C extensions compiled
for 1.5.2 must be recompiled in order to work with 2.0. On Windows, it&#8217;s not
possible for Python 2.0 to import a third party extension built for Python 1.5.x
due to how Windows DLLs work, so Python will raise an exception and the import
will fail.
Users of Jim Fulton&#8217;s ExtensionClass module will be pleased to find out that
hooks have been added so that ExtensionClasses are now supported by
<a class="reference internal" href="../library/functions.html#isinstance" title="isinstance"><tt class="xref py py-func docutils literal">isinstance()</tt></a> and <a class="reference internal" href="../library/functions.html#issubclass" title="issubclass"><tt class="xref py py-func docutils literal">issubclass()</tt></a>. This means you no longer have to
remember to write code such as <tt class="docutils literal">if type(obj) == myExtensionClass</tt>, but can use
the more natural <tt class="docutils literal">if isinstance(obj, myExtensionClass)</tt>.
The <tt class="file docutils literal">Python/importdl.c</tt> file, which was a mass of #ifdefs to support
dynamic loading on many different platforms, was cleaned up and reorganised by
Greg Stein. <tt class="file docutils literal">importdl.c</tt> is now quite small, and platform-specific code
has been moved into a bunch of <tt class="file docutils literal">Python/dynload_*.c</tt> files. Another
cleanup: there were also a number of <tt class="file docutils literal">my*.h</tt> files in the Include/
directory that held various portability hacks; they&#8217;ve been merged into a single
file, <tt class="file docutils literal">Include/pyport.h</tt>.
Vladimir Marangozov&#8217;s long-awaited malloc restructuring was completed, to make
it easy to have the Python interpreter use a custom allocator instead of C&#8217;s
standard <tt class="xref py py-func docutils literal">malloc()</tt>. For documentation, read the comments in
<tt class="file docutils literal">Include/pymem.h</tt> and <tt class="file docutils literal">Include/objimpl.h</tt>. For the lengthy
discussions during which the interface was hammered out, see the Web archives of
the &#8216;patches&#8217; and &#8216;python-dev&#8217; lists at python.org.
Recent versions of the GUSI development environment for MacOS support POSIX
threads. Therefore, Python&#8217;s POSIX threading support now works on the
Macintosh. Threading support using the user-space GNU <tt class="docutils literal">pth</tt> library was also
contributed.
Threading support on Windows was enhanced, too. Windows supports thread locks
that use kernel objects only in case of contention; in the common case when
there&#8217;s no contention, they use simpler functions which are an order of
magnitude faster. A threaded version of Python 1.5.2 on NT is twice as slow as
an unthreaded version; with the 2.0 changes, the difference is only 10%. These
improvements were contributed by Yakov Markovitch.
Python 2.0&#8217;s source now uses only ANSI C prototypes, so compiling Python now
requires an ANSI C compiler, and can no longer be done using a compiler that
only supports K&amp;R C.
Previously the Python virtual machine used 16-bit numbers in its bytecode,
limiting the size of source files. In particular, this affected the maximum
size of literal lists and dictionaries in Python source; occasionally people who
are generating Python code would run into this limit. A patch by Charles G.
Waldman raises the limit from <tt class="docutils literal">2^16</tt> to <tt class="docutils literal">2^{32}</tt>.
Three new convenience functions intended for adding constants to a module&#8217;s
dictionary at module initialization time were added: <tt class="xref py py-func docutils literal">PyModule_AddObject()</tt>,
<tt class="xref py py-func docutils literal">PyModule_AddIntConstant()</tt>, and <tt class="xref py py-func docutils literal">PyModule_AddStringConstant()</tt>. Each
of these functions takes a module object, a null-terminated C string containing
the name to be added, and a third argument for the value to be assigned to the
name. This third argument is, respectively, a Python object, a C long, or a C
string.
A wrapper API was added for Unix-style signal handlers. <tt class="xref py py-func docutils literal">PyOS_getsig()</tt> gets
a signal handler and <tt class="xref py py-func docutils literal">PyOS_setsig()</tt> will set a new handler.
</div>
<div class="section" id="distutils-making-modules-easy-to-install">
<h2>Distutils: Making Modules Easy to Install<a class="headerlink" href="#distutils-making-modules-easy-to-install" title="Permalink to this headline">¶</a></h2>
Before Python 2.0, installing modules was a tedious affair &#8211; there was no way
to figure out automatically where Python is installed, or what compiler options
to use for extension modules. Software authors had to go through an arduous
ritual of editing Makefiles and configuration files, which only really work on
Unix and leave Windows and MacOS unsupported. Python users faced wildly
differing installation instructions which varied between different extension
packages, which made administering a Python installation something of a chore.
The SIG for distribution utilities, shepherded by Greg Ward, has created the
Distutils, a system to make package installation much easier. They form the
<a class="reference internal" href="../library/distutils.html#module-distutils" title="distutils: Support for building and installing Python modules into an existing Python installation."><tt class="xref py py-mod docutils literal">distutils</tt></a> package, a new part of Python&#8217;s standard library. In the best
case, installing a Python module from source will require the same steps: first
you simply mean unpack the tarball or zip archive, and the run &#8220;<tt class="docutils literal">python
setup.py install</tt>&#8221;. The platform will be automatically detected, the compiler
will be recognized, C extension modules will be compiled, and the distribution
installed into the proper directory. Optional command-line arguments provide
more control over the installation process, the distutils package offers many
places to override defaults &#8211; separating the build from the install, building
or installing in non-default directories, and more.
In order to use the Distutils, you need to write a <tt class="file docutils literal">setup.py</tt> script. For
the simple case, when the software contains only .py files, a minimal
<tt class="file docutils literal">setup.py</tt> can be just a few lines long:
<div class="highlight-python"><div class="highlight"><pre>from distutils.core import setup
setup (name = &quot;foo&quot;, version = &quot;1.0&quot;,
 py_modules = [&quot;module1&quot;, &quot;module2&quot;])
</pre></div>
</div>
The <tt class="file docutils literal">setup.py</tt> file isn&#8217;t much more complicated if the software consists
of a few packages:
<div class="highlight-python"><div class="highlight"><pre>from distutils.core import setup
setup (name = &quot;foo&quot;, version = &quot;1.0&quot;,
 packages = [&quot;package&quot;, &quot;package.subpackage&quot;])
</pre></div>
</div>
A C extension can be the most complicated case; here&#8217;s an example taken from
the PyXML package:
<div class="highlight-python"><div class="highlight"><pre>from distutils.core import setup, Extension

expat_extension = Extension(&#39;xml.parsers.pyexpat&#39;,
 define_macros = [(&#39;XML_NS&#39;, None)],
 include_dirs = [ &#39;extensions/expat/xmltok&#39;,
 &#39;extensions/expat/xmlparse&#39; ],
 sources = [ &#39;extensions/pyexpat.c&#39;,
 &#39;extensions/expat/xmltok/xmltok.c&#39;,
 &#39;extensions/expat/xmltok/xmlrole.c&#39;, ]
 )
setup (name = &quot;PyXML&quot;, version = &quot;0.5.4&quot;,
 ext_modules =[ expat_extension ] )
</pre></div>
</div>
The Distutils can also take care of creating source and binary distributions.
The &#8220;sdist&#8221; command, run by &#8220;<tt class="docutils literal">python setup.py sdist</tt>&#8216;, builds a source
distribution such as <tt class="file docutils literal">foo-1.0.tar.gz</tt>. Adding new commands isn&#8217;t
difficult, &#8220;bdist_rpm&#8221; and &#8220;bdist_wininst&#8221; commands have already been
contributed to create an RPM distribution and a Windows installer for the
software, respectively. Commands to create other distribution formats such as
Debian packages and Solaris <tt class="file docutils literal">.pkg</tt> files are in various stages of
development.
All this is documented in a new manual, Distributing Python Modules, that
joins the basic set of Python documentation.
</div>
<div class="section" id="xml-modules">
<h2>XML Modules<a class="headerlink" href="#xml-modules" title="Permalink to this headline">¶</a></h2>
Python 1.5.2 included a simple XML parser in the form of the <tt class="xref py py-mod docutils literal">xmllib</tt>
module, contributed by Sjoerd Mullender. Since 1.5.2&#8217;s release, two different
interfaces for processing XML have become common: SAX2 (version 2 of the Simple
API for XML) provides an event-driven interface with some similarities to
<tt class="xref py py-mod docutils literal">xmllib</tt>, and the DOM (Document Object Model) provides a tree-based
interface, transforming an XML document into a tree of nodes that can be
traversed and modified. Python 2.0 includes a SAX2 interface and a stripped-
down DOM interface as part of the <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><tt class="xref py py-mod docutils literal">xml</tt></a> package. Here we will give a brief
overview of these new interfaces; consult the Python documentation or the source
code for complete details. The Python XML SIG is also working on improved
documentation.
<div class="section" id="sax2-support">
<h3>SAX2 Support<a class="headerlink" href="#sax2-support" title="Permalink to this headline">¶</a></h3>
SAX defines an event-driven interface for parsing XML. To use SAX, you must
write a SAX handler class. Handler classes inherit from various classes
provided by SAX, and override various methods that will then be called by the
XML parser. For example, the <tt class="xref py py-meth docutils literal">startElement()</tt> and <tt class="xref py py-meth docutils literal">endElement()</tt>
methods are called for every starting and end tag encountered by the parser, the
<tt class="xref py py-meth docutils literal">characters()</tt> method is called for every chunk of character data, and so
forth.
The advantage of the event-driven approach is that the whole document doesn&#8217;t
have to be resident in memory at any one time, which matters if you are
processing really huge documents. However, writing the SAX handler class can
get very complicated if you&#8217;re trying to modify the document structure in some
elaborate way.
For example, this little example program defines a handler that prints a message
for every starting and ending tag, and then parses the file <tt class="file docutils literal">hamlet.xml</tt>
using it:
<div class="highlight-python"><div class="highlight"><pre>from xml import sax

class SimpleHandler(sax.ContentHandler):
 def startElement(self, name, attrs):
 print &#39;Start of element:&#39;, name, attrs.keys()

def endElement(self, name):
 print &#39;End of element:&#39;, name

# Create a parser object
parser = sax.make_parser()

# Tell it what handler to use
handler = SimpleHandler()
parser.setContentHandler( handler )

# Parse a file!
parser.parse( &#39;hamlet.xml&#39; )
</pre></div>
</div>
For more information, consult the Python documentation, or the XML HOWTO at
<a class="reference external" href="http://pyxml.sourceforge.net/topics/howto/xml-howto.html">http://pyxml.sourceforge.net/topics/howto/xml-howto.html</a>.
</div>
<div class="section" id="dom-support">
<h3>DOM Support<a class="headerlink" href="#dom-support" title="Permalink to this headline">¶</a></h3>
The Document Object Model is a tree-based representation for an XML document. A
top-level <tt class="xref py py-class docutils literal">Document</tt> instance is the root of the tree, and has a single
child which is the top-level <tt class="xref py py-class docutils literal">Element</tt> instance. This <tt class="xref py py-class docutils literal">Element</tt>
has children nodes representing character data and any sub-elements, which may
have further children of their own, and so forth. Using the DOM you can
traverse the resulting tree any way you like, access element and attribute
values, insert and delete nodes, and convert the tree back into XML.
The DOM is useful for modifying XML documents, because you can create a DOM
tree, modify it by adding new nodes or rearranging subtrees, and then produce a
new XML document as output. You can also construct a DOM tree manually and
convert it to XML, which can be a more flexible way of producing XML output than
simply writing <tt class="docutils literal">&lt;tag1&gt;</tt>...<tt class="docutils literal">&lt;/tag1&gt;</tt> to a file.
The DOM implementation included with Python lives in the <a class="reference internal" href="../library/xml.dom.minidom.html#module-xml.dom.minidom" title="xml.dom.minidom: Minimal Document Object Model (DOM) implementation."><tt class="xref py py-mod docutils literal">xml.dom.minidom</tt></a>
module. It&#8217;s a lightweight implementation of the Level 1 DOM with support for
XML namespaces. The <tt class="xref py py-func docutils literal">parse()</tt> and <tt class="xref py py-func docutils literal">parseString()</tt> convenience
functions are provided for generating a DOM tree:
<div class="highlight-python"><div class="highlight"><pre>from xml.dom import minidom
doc = minidom.parse(&#39;hamlet.xml&#39;)
</pre></div>
</div>
<tt class="docutils literal">doc</tt> is a <tt class="xref py py-class docutils literal">Document</tt> instance. <tt class="xref py py-class docutils literal">Document</tt>, like all the other
DOM classes such as <tt class="xref py py-class docutils literal">Element</tt> and <tt class="xref py py-class docutils literal">Text</tt>, is a subclass of the
<tt class="xref py py-class docutils literal">Node</tt> base class. All the nodes in a DOM tree therefore support certain
common methods, such as <tt class="xref py py-meth docutils literal">toxml()</tt> which returns a string containing the XML
representation of the node and its children. Each class also has special
methods of its own; for example, <tt class="xref py py-class docutils literal">Element</tt> and <tt class="xref py py-class docutils literal">Document</tt>
instances have a method to find all child elements with a given tag name.
Continuing from the previous 2-line example:
<div class="highlight-python"><div class="highlight"><pre>perslist = doc.getElementsByTagName( &#39;PERSONA&#39; )
print perslist[0].toxml()
print perslist[1].toxml()
</pre></div>
</div>
For the Hamlet XML file, the above few lines output:
<div class="highlight-python"><pre>&lt;PERSONA&gt;CLAUDIUS, king of Denmark. &lt;/PERSONA&gt;
&lt;PERSONA&gt;HAMLET, son to the late, and nephew to the present king.&lt;/PERSONA&gt;</pre>
</div>
The root element of the document is available as <tt class="docutils literal">doc.documentElement</tt>, and
its children can be easily modified by deleting, adding, or removing nodes:
<div class="highlight-python"><div class="highlight"><pre>root = doc.documentElement

# Remove the first child
root.removeChild( root.childNodes[0] )

# Move the new first child to the end
root.appendChild( root.childNodes[0] )

# Insert the new first child (originally,
# the third child) before the 20th child.
root.insertBefore( root.childNodes[0], root.childNodes[20] )
</pre></div>
</div>
Again, I will refer you to the Python documentation for a complete listing of
the different <tt class="xref py py-class docutils literal">Node</tt> classes and their various methods.
</div>
<div class="section" id="relationship-to-pyxml">
<h3>Relationship to PyXML<a class="headerlink" href="#relationship-to-pyxml" title="Permalink to this headline">¶</a></h3>
The XML Special Interest Group has been working on XML-related Python code for a
while. Its code distribution, called PyXML, is available from the SIG&#8217;s Web
pages at <a class="reference external" href="http://www.python.org/sigs/xml-sig/">http://www.python.org/sigs/xml-sig/</a>. The PyXML distribution also used
the package name <tt class="docutils literal">xml</tt>. If you&#8217;ve written programs that used PyXML, you&#8217;re
probably wondering about its compatibility with the 2.0 <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><tt class="xref py py-mod docutils literal">xml</tt></a> package.
The answer is that Python 2.0&#8217;s <a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><tt class="xref py py-mod docutils literal">xml</tt></a> package isn&#8217;t compatible with PyXML,
but can be made compatible by installing a recent version PyXML. Many
applications can get by with the XML support that is included with Python 2.0,
but more complicated applications will require that the full PyXML package will
be installed. When installed, PyXML versions 0.6.0 or greater will replace the
<a class="reference internal" href="../library/xml.html#module-xml" title="xml: Package containing XML processing modules"><tt class="xref py py-mod docutils literal">xml</tt></a> package shipped with Python, and will be a strict superset of the
standard package, adding a bunch of additional features. Some of the additional
features in PyXML include:
<ul class="simple">
<li>4DOM, a full DOM implementation from FourThought, Inc.</li>
<li>The xmlproc validating parser, written by Lars Marius Garshol.</li>
<li>The <tt class="xref py py-mod docutils literal">sgmlop</tt> parser accelerator module, written by Fredrik Lundh.</li>
</ul>
</div>
</div>
<div class="section" id="module-changes">
<h2>Module changes<a class="headerlink" href="#module-changes" title="Permalink to this headline">¶</a></h2>
Lots of improvements and bugfixes were made to Python&#8217;s extensive standard
library; some of the affected modules include <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><tt class="xref py py-mod docutils literal">readline</tt></a>,
<a class="reference internal" href="../library/configparser.html#module-ConfigParser" title="ConfigParser: Configuration file parser."><tt class="xref py py-mod docutils literal">ConfigParser</tt></a>, <a class="reference internal" href="../library/cgi.html#module-cgi" title="cgi: Helpers for running Python scripts via the Common Gateway Interface."><tt class="xref py py-mod docutils literal">cgi</tt></a>, <a class="reference internal" href="../library/calendar.html#module-calendar" title="calendar: Functions for working with calendars, including some emulation of the Unix cal program."><tt class="xref py py-mod docutils literal">calendar</tt></a>, <a class="reference internal" href="../library/posix.html#module-posix" title="posix: The most common POSIX system calls (normally used via module os). (Unix)"><tt class="xref py py-mod docutils literal">posix</tt></a>, <a class="reference internal" href="../library/readline.html#module-readline" title="readline: GNU readline support for Python. (Unix)"><tt class="xref py py-mod docutils literal">readline</tt></a>,
<tt class="xref py py-mod docutils literal">xmllib</tt>, <a class="reference internal" href="../library/aifc.html#module-aifc" title="aifc: Read and write audio files in AIFF or AIFC format."><tt class="xref py py-mod docutils literal">aifc</tt></a>, <tt class="xref py py-mod docutils literal">chunk, wave</tt>, <a class="reference internal" href="../library/random.html#module-random" title="random: Generate pseudo-random numbers with various common distributions."><tt class="xref py py-mod docutils literal">random</tt></a>, <a class="reference internal" href="../library/shelve.html#module-shelve" title="shelve: Python object persistence."><tt class="xref py py-mod docutils literal">shelve</tt></a>,
and <a class="reference internal" href="../library/nntplib.html#module-nntplib" title="nntplib: NNTP protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">nntplib</tt></a>. Consult the CVS logs for the exact patch-by-patch details.
Brian Gallew contributed OpenSSL support for 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. OpenSSL
is an implementation of the Secure Socket Layer, which encrypts the data being
sent over a socket. When compiling Python, you can edit <tt class="file docutils literal">Modules/Setup</tt>
to include SSL support, which adds an additional function to the <a class="reference internal" href="../library/socket.html#module-socket" title="socket: Low-level networking interface."><tt class="xref py py-mod docutils literal">socket</tt></a>
module: <tt class="xref py py-func docutils literal">socket.ssl(socket, keyfile, certfile)()</tt>, which takes a socket
object and returns an SSL socket. The <a class="reference internal" href="../library/httplib.html#module-httplib" title="httplib: HTTP and HTTPS protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">httplib</tt></a> and <a class="reference internal" href="../library/urllib.html#module-urllib" title="urllib: Open an arbitrary network resource by URL (requires sockets)."><tt class="xref py py-mod docutils literal">urllib</tt></a> modules
were also changed to support <tt class="docutils literal">https://</tt> URLs, though no one has implemented
FTP or SMTP over SSL.
The <a class="reference internal" href="../library/httplib.html#module-httplib" title="httplib: HTTP and HTTPS protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">httplib</tt></a> module has been rewritten by Greg Stein to support HTTP/1.1.
Backward compatibility with the 1.5 version of <a class="reference internal" href="../library/httplib.html#module-httplib" title="httplib: HTTP and HTTPS protocol client (requires sockets)."><tt class="xref py py-mod docutils literal">httplib</tt></a> is provided,
though using HTTP/1.1 features such as pipelining will require rewriting code to
use a different set of interfaces.
The <a class="reference internal" href="../library/tkinter.html#module-Tkinter" title="Tkinter: Interface to Tcl/Tk for graphical user interfaces"><tt class="xref py py-mod docutils literal">Tkinter</tt></a> module now supports Tcl/Tk version 8.1, 8.2, or 8.3, and
support for the older 7.x versions has been dropped. The Tkinter module now
supports displaying Unicode strings in Tk widgets. Also, Fredrik Lundh
contributed an optimization which makes operations like <tt class="docutils literal">create_line</tt> and
<tt class="docutils literal">create_polygon</tt> much faster, especially when using lots of coordinates.
The <a class="reference internal" href="../library/curses.html#module-curses" title="curses: An interface to the curses library, providing portable terminal handling. (Unix)"><tt class="xref py py-mod docutils literal">curses</tt></a> module has been greatly extended, starting from Oliver
Andrich&#8217;s enhanced version, to provide many additional functions from ncurses
and SYSV curses, such as colour, alternative character set support, pads, and
mouse support. This means the module is no longer compatible with operating
systems that only have BSD curses, but there don&#8217;t seem to be any currently
maintained OSes that fall into this category.
As mentioned in the earlier discussion of 2.0&#8217;s Unicode support, the underlying
implementation of the regular expressions provided by the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><tt class="xref py py-mod docutils literal">re</tt></a> module has
been changed. SRE, a new regular expression engine written by Fredrik Lundh and
partially funded by Hewlett Packard, supports matching against both 8-bit
strings and Unicode strings.
</div>
<div class="section" id="new-modules">
<h2>New modules<a class="headerlink" href="#new-modules" title="Permalink to this headline">¶</a></h2>
A number of new modules were added. We&#8217;ll simply list them with brief
descriptions; consult the 2.0 documentation for the details of a particular
module.
<ul class="simple">
<li><a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><tt class="xref py py-mod docutils literal">atexit</tt></a>: For registering functions to be called before the Python
interpreter exits. Code that currently sets <tt class="docutils literal">sys.exitfunc</tt> directly should be
changed to use the <a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><tt class="xref py py-mod docutils literal">atexit</tt></a> module instead, importing <a class="reference internal" href="../library/atexit.html#module-atexit" title="atexit: Register and execute cleanup functions."><tt class="xref py py-mod docutils literal">atexit</tt></a> and
calling <a class="reference internal" href="../library/atexit.html#atexit.register" title="atexit.register"><tt class="xref py py-func docutils literal">atexit.register()</tt></a> with the function to be called on exit.
(Contributed by Skip Montanaro.)</li>
<li><a class="reference internal" href="../library/codecs.html#module-codecs" title="codecs: Encode and decode data and streams."><tt class="xref py py-mod docutils literal">codecs</tt></a>, <tt class="xref py py-mod docutils literal">encodings</tt>, <a class="reference internal" href="../library/unicodedata.html#module-unicodedata" title="unicodedata: Access the Unicode Database."><tt class="xref py py-mod docutils literal">unicodedata</tt></a>: Added as part of the new
Unicode support.</li>
<li><a class="reference internal" href="../library/filecmp.html#module-filecmp" title="filecmp: Compare files efficiently."><tt class="xref py py-mod docutils literal">filecmp</tt></a>: Supersedes the old <a class="reference internal" href="../library/functions.html#cmp" title="cmp"><tt class="xref py py-mod docutils literal">cmp</tt></a>, <tt class="xref py py-mod docutils literal">cmpcache</tt> and
<tt class="xref py py-mod docutils literal">dircmp</tt> modules, which have now become deprecated. (Contributed by Gordon
MacMillan and Moshe Zadka.)</li>
<li><a class="reference internal" href="../library/gettext.html#module-gettext" title="gettext: Multilingual internationalization services."><tt class="xref py py-mod docutils literal">gettext</tt></a>: This module provides internationalization (I18N) and
localization (L10N) support for Python programs by providing an interface to the
GNU gettext message catalog library. (Integrated by Barry Warsaw, from separate
contributions by Martin von Löwis, Peter Funk, and James Henstridge.)</li>
<li><tt class="xref py py-mod docutils literal">linuxaudiodev</tt>: Support for the <tt class="file docutils literal">/dev/audio</tt> device on Linux, a
twin to the existing <a class="reference internal" href="../library/sunaudio.html#module-sunaudiodev" title="sunaudiodev: Access to Sun audio hardware. (deprecated) (SunOS)"><tt class="xref py py-mod docutils literal">sunaudiodev</tt></a> module. (Contributed by Peter Bosch,
with fixes by Jeremy Hylton.)</li>
<li><a class="reference internal" href="../library/mmap.html#module-mmap" title="mmap: Interface to memory-mapped files for Unix and Windows."><tt class="xref py py-mod docutils literal">mmap</tt></a>: An interface to memory-mapped files on both Windows and Unix. A
file&#8217;s contents can be mapped directly into memory, at which point it behaves
like a mutable string, so its contents can be read and modified. They can even
be passed to functions that expect ordinary strings, such as the <a class="reference internal" href="../library/re.html#module-re" title="re: Regular expression operations."><tt class="xref py py-mod docutils literal">re</tt></a>
module. (Contributed by Sam Rushing, with some extensions by A.M. Kuchling.)</li>
<li><tt class="xref py py-mod docutils literal">pyexpat</tt>: An interface to the Expat XML parser. (Contributed by Paul
Prescod.)</li>
<li><a class="reference internal" href="../library/robotparser.html#module-robotparser" title="robotparser: Loads a robots.txt file and answers questions about fetchability of other URLs."><tt class="xref py py-mod docutils literal">robotparser</tt></a>: Parse a <tt class="file docutils literal">robots.txt</tt> file, which is used for writing
Web spiders that politely avoid certain areas of a Web site. The parser accepts
the contents of a <tt class="file docutils literal">robots.txt</tt> file, builds a set of rules from it, and
can then answer questions about the fetchability of a given URL. (Contributed
by Skip Montanaro.)</li>
<li><a class="reference internal" href="../library/tabnanny.html#module-tabnanny" title="tabnanny: Tool for detecting white space related problems in Python source files in a directory tree."><tt class="xref py py-mod docutils literal">tabnanny</tt></a>: A module/script to check Python source code for ambiguous
indentation. (Contributed by Tim Peters.)</li>
<li><a class="reference internal" href="../library/userdict.html#module-UserString" title="UserString: Class wrapper for string objects."><tt class="xref py py-mod docutils literal">UserString</tt></a>: A base class useful for deriving objects that behave like
strings.</li>
<li><a class="reference internal" href="../library/webbrowser.html#module-webbrowser" title="webbrowser: Easy-to-use controller for Web browsers."><tt class="xref py py-mod docutils literal">webbrowser</tt></a>: A module that provides a platform independent way to launch
a web browser on a specific URL. For each platform, various browsers are tried
in a specific order. The user can alter which browser is launched by setting the
BROWSER environment variable. (Originally inspired by Eric S. Raymond&#8217;s patch
to <a class="reference internal" href="../library/urllib.html#module-urllib" title="urllib: Open an arbitrary network resource by URL (requires sockets)."><tt class="xref py py-mod docutils literal">urllib</tt></a> which added similar functionality, but the final module comes
from code originally implemented by Fred Drake as
<tt class="file docutils literal">Tools/idle/BrowserControl.py</tt>, and adapted for the standard library by
Fred.)</li>
<li><a class="reference internal" href="../library/_winreg.html#module-_winreg" title="_winreg: Routines and objects for manipulating the Windows registry. (Windows)"><tt class="xref py py-mod docutils literal">_winreg</tt></a>: An interface to the Windows registry. <a class="reference internal" href="../library/_winreg.html#module-_winreg" title="_winreg: Routines and objects for manipulating the Windows registry. (Windows)"><tt class="xref py py-mod docutils literal">_winreg</tt></a> is an
adaptation of functions that have been part of PythonWin since 1995, but has now
been added to the core distribution, and enhanced to support Unicode.
<a class="reference internal" href="../library/_winreg.html#module-_winreg" title="_winreg: Routines and objects for manipulating the Windows registry. (Windows)"><tt class="xref py py-mod docutils literal">_winreg</tt></a> was written by Bill Tutt and Mark Hammond.</li>
<li><a class="reference internal" href="../library/zipfile.html#module-zipfile" title="zipfile: Read and write ZIP-format archive files."><tt class="xref py py-mod docutils literal">zipfile</tt></a>: A module for reading and writing ZIP-format archives. These
are archives produced by PKZIP on DOS/Windows or zip on
Unix, not to be confused with gzip-format files (which are
supported by the <a class="reference internal" href="../library/gzip.html#module-gzip" title="gzip: Interfaces for gzip compression and decompression using file objects."><tt class="xref py py-mod docutils literal">gzip</tt></a> module) (Contributed by James C. Ahlstrom.)</li>
<li><a class="reference internal" href="../library/imputil.html#module-imputil" title="imputil: Manage and augment the import process. (deprecated)"><tt class="xref py py-mod docutils literal">imputil</tt></a>: A module that provides a simpler way for writing customised
import hooks, in comparison to the existing <tt class="xref py py-mod docutils literal">ihooks</tt> module. (Implemented
by Greg Stein, with much discussion on python-dev along the way.)</li>
</ul>
</div>
<div class="section" id="idle-improvements">
<h2>IDLE Improvements<a class="headerlink" href="#idle-improvements" title="Permalink to this headline">¶</a></h2>
IDLE is the official Python cross-platform IDE, written using Tkinter. Python
2.0 includes IDLE 0.6, which adds a number of new features and improvements. A
partial list:
<ul class="simple">
<li>UI improvements and optimizations, especially in the area of syntax
highlighting and auto-indentation.</li>
<li>The class browser now shows more information, such as the top level functions
in a module.</li>
<li>Tab width is now a user settable option. When opening an existing Python file,
IDLE automatically detects the indentation conventions, and adapts.</li>
<li>There is now support for calling browsers on various platforms, used to open
the Python documentation in a browser.</li>
<li>IDLE now has a command line, which is largely similar to the vanilla Python
interpreter.</li>
<li>Call tips were added in many places.</li>
<li>IDLE can now be installed as a package.</li>
<li>In the editor window, there is now a line/column bar at the bottom.</li>
<li>Three new keystroke commands: Check module (Alt-F5), Import module (F5) and
Run script (Ctrl-F5).</li>
</ul>
</div>
<div class="section" id="deleted-and-deprecated-modules">
<h2>Deleted and Deprecated Modules<a class="headerlink" href="#deleted-and-deprecated-modules" title="Permalink to this headline">¶</a></h2>
A few modules have been dropped because they&#8217;re obsolete, or because there are
now better ways to do the same thing. The <tt class="xref py py-mod docutils literal">stdwin</tt> module is gone; it was
for a platform-independent windowing toolkit that&#8217;s no longer developed.
A number of modules have been moved to the <tt class="file docutils literal">lib-old</tt> subdirectory:
<a class="reference internal" href="../library/functions.html#cmp" title="cmp"><tt class="xref py py-mod docutils literal">cmp</tt></a>, <tt class="xref py py-mod docutils literal">cmpcache</tt>, <tt class="xref py py-mod docutils literal">dircmp</tt>, <tt class="xref py py-mod docutils literal">dump</tt>, <tt class="xref py py-mod docutils literal">find</tt>,
<tt class="xref py py-mod docutils literal">grep</tt>, <tt class="xref py py-mod docutils literal">packmail</tt>, <tt class="xref py py-mod docutils literal">poly</tt>, <tt class="xref py py-mod docutils literal">util</tt>, <tt class="xref py py-mod docutils literal">whatsound</tt>,
<tt class="xref py py-mod docutils literal">zmod</tt>. If you have code which relies on a module that&#8217;s been moved to
<tt class="file docutils literal">lib-old</tt>, you can simply add that directory to <tt class="docutils literal">sys.path</tt> to get them
back, but you&#8217;re encouraged to update any code that uses these modules.
</div>
<div class="section" id="acknowledgements">
<h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Permalink to this headline">¶</a></h2>
The authors would like to thank the following people for offering suggestions on
various drafts of this article: David Bolen, Mark Hammond, Gregg Hauser, Jeremy
Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir
Marangozov, Tobias Polzin, Guido van Rossum, Neil Schemenauer, and Russ Schmidt.
</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.0</a><ul>
<li><a class="reference internal" href="#introduction">Introduction</a></li>
<li><a class="reference internal" href="#what-about-python-1-6">What About Python 1.6?</a></li>
<li><a class="reference internal" href="#new-development-process">New Development Process</a></li>
<li><a class="reference internal" href="#unicode">Unicode</a></li>
<li><a class="reference internal" href="#list-comprehensions">List Comprehensions</a></li>
<li><a class="reference internal" href="#augmented-assignment">Augmented Assignment</a></li>
<li><a class="reference internal" href="#string-methods">String Methods</a></li>
<li><a class="reference internal" href="#garbage-collection-of-cycles">Garbage Collection of Cycles</a></li>
<li><a class="reference internal" href="#other-core-changes">Other Core Changes</a><ul>
<li><a class="reference internal" href="#minor-language-changes">Minor Language Changes</a></li>
<li><a class="reference internal" href="#changes-to-built-in-functions">Changes to Built-in Functions</a></li>
</ul>
</li>
<li><a class="reference internal" href="#porting-to-2-0">Porting to 2.0</a></li>
<li><a class="reference internal" href="#extending-embedding-changes">Extending/Embedding Changes</a></li>
<li><a class="reference internal" href="#distutils-making-modules-easy-to-install">Distutils: Making Modules Easy to Install</a></li>
<li><a class="reference internal" href="#xml-modules">XML Modules</a><ul>
<li><a class="reference internal" href="#sax2-support">SAX2 Support</a></li>
<li><a class="reference internal" href="#dom-support">DOM Support</a></li>
<li><a class="reference internal" href="#relationship-to-pyxml">Relationship to PyXML</a></li>
</ul>
</li>
<li><a class="reference internal" href="#module-changes">Module changes</a></li>
<li><a class="reference internal" href="#new-modules">New modules</a></li>
<li><a class="reference internal" href="#idle-improvements">IDLE Improvements</a></li>
<li><a class="reference internal" href="#deleted-and-deprecated-modules">Deleted and Deprecated Modules</a></li>
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
</ul>
</li>
</ul>

<h4>Previous topic</h4>
 <a href="2.1.html"
 title="previous chapter">What&#8217;s New in Python 2.1</a>
 <h4>Next topic</h4>
 <a href="../tutorial/index.html"
 title="next chapter">The Python Tutorial</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.0.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="../tutorial/index.html" title="The Python Tutorial"
 >next</a> |</li>
 <li class="right" >
 <a href="2.1.html" title="What’s New in Python 2.1"
 >previous</a> |</li>
 <li><img src="../_static/py.png" alt=""
 style="vertical-align: middle; margin-top: -1px"/></li>
 <li><a href="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>

${this.title}

Code Editor : 2.0.html