[Stackless-checkins] CVS: slpdev/src/2.2/src/Doc/whatsnew whatsnew20.tex, NONE, 1.1 whatsnew21.tex, NONE, 1.1 whatsnew23.tex, NONE, 1.1 whatsnew24.tex, NONE, 1.1

Christian Tismer tismer at centera.de
Sat May 1 02:54:05 CEST 2004


Update of /home/cvs/slpdev/src/2.2/src/Doc/whatsnew
In directory centera.de:/home/tismer/slpdev/src/2.2/src/Doc/whatsnew

Added Files:
	whatsnew20.tex whatsnew21.tex whatsnew23.tex whatsnew24.tex 
Log Message:
added files

--- NEW FILE: whatsnew20.tex ---
\documentclass{howto}

% $Id: whatsnew20.tex,v 1.1 2004/05/01 00:54:02 tismer Exp $

\title{What's New in Python 2.0}
\release{1.02}
\author{A.M. Kuchling and Moshe Zadka}
\authoraddress{
	\strong{Python Software Foundation}\\
	Email: \email{amk at amk.ca}, \email{moshez at twistedmatrix.com}
}
\begin{document}
\maketitle\tableofcontents

\section{Introduction}

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
[...1297 lines suppressed...]

A number of modules have been moved to the
\file{lib-old} subdirectory:
\module{cmp}, \module{cmpcache}, \module{dircmp}, \module{dump}, 
\module{find}, \module{grep}, \module{packmail}, 
\module{poly}, \module{util}, \module{whatsound}, \module{zmod}. 
If you have code which relies on a module  that's been moved to
\file{lib-old}, you can simply add that directory to \code{sys.path}  
to get them back, but you're encouraged to update any code that uses
these modules.

\section{Acknowledgements}

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.

\end{document}

--- NEW FILE: whatsnew21.tex ---
\documentclass{howto}

\usepackage{distutils}

% $Id: whatsnew21.tex,v 1.1 2004/05/01 00:54:02 tismer Exp $

\title{What's New in Python 2.1}
\release{1.00}
\author{A.M. Kuchling}
\authoraddress{
	\strong{Python Software Foundation}\\
	Email: \email{amk at amk.ca}
}
\begin{document}
\maketitle\tableofcontents

\section{Introduction}

It's that time again... time for a new Python release, Python 2.1.
One recent goal of the Python development team has been to accelerate
the pace of new releases, with a new release coming every 6 to 9
months. 2.1 is the first release to come out at this faster pace, with
the first alpha appearing in January, 3 months after the final version
of 2.0 was released.

This article explains the new features in 2.1.  While there aren't as
many changes in 2.1 as there were in Python 2.0, there are still some
pleasant surprises in store.  2.1 is the first release to be steered
through the use of Python Enhancement Proposals, or PEPs, so most of
the sizable changes have accompanying PEPs that provide more complete
documentation and a design rationale for the change.  This article
doesn't attempt to document the new features completely, but simply
provides an overview of the new features for Python programmers.
Refer to the Python 2.1 documentation, or to the specific PEP, for
more details about any new feature that particularly interests you.

The final release of Python 2.1 was made on April 17, 2001.

%======================================================================
\section{PEP 227: Nested Scopes}

The largest change in Python 2.1 is to Python's scoping rules.  In
Python 2.0, at any given time there are at most three namespaces used
to look up variable names: local, module-level, and the built-in
namespace.  This often surprised people because it didn't match their
intuitive expectations.  For example, a nested recursive function
definition doesn't work:

\begin{verbatim}
def f():
    ...
    def g(value):
        ...
        return g(value-1) + 1
    ...
\end{verbatim}

The function \function{g()} will always raise a \exception{NameError}
exception, because the binding of the name \samp{g} isn't in either
its local namespace or in the module-level namespace.  This isn't much
of a problem in practice (how often do you recursively define interior
functions like this?), but this also made using the \keyword{lambda}
statement clumsier, and this was a problem in practice.  In code which
uses \keyword{lambda} you can often find local variables being copied
by passing them as the default values of arguments.

\begin{verbatim}
def find(self, name):
    "Return list of any entries equal to 'name'"
    L = filter(lambda x, name=name: x == name,
               self.list_attribute)
    return L
\end{verbatim}

The readability of Python code written in a strongly functional style
suffers greatly as a result.

The most significant change to Python 2.1 is that static scoping has
been added to the language to fix this problem.  As a first effect,
the \code{name=name} default argument is now unnecessary in the above
example.  Put simply, when a given variable name is not assigned a
value within a function (by an assignment, or the \keyword{def},
\keyword{class}, or \keyword{import} statements), references to the
variable will be looked up in the local namespace of the enclosing
scope.  A more detailed explanation of the rules, and a dissection of
the implementation, can be found in the PEP.

This change may cause some compatibility problems for code where the
same variable name is used both at the module level and as a local
variable within a function that contains further function definitions.
This seems rather unlikely though, since such code would have been
pretty confusing to read in the first place.  

One side effect of the change is that the \code{from \var{module}
import *} and \keyword{exec} statements have been made illegal inside
a function scope under certain conditions.  The Python reference
manual has said all along that \code{from \var{module} import *} is
only legal at the top level of a module, but the CPython interpreter
has never enforced this before.  As part of the implementation of
nested scopes, the compiler which turns Python source into bytecodes
has to generate different code to access variables in a containing
scope.  \code{from \var{module} import *} and \keyword{exec} make it
impossible for the compiler to figure this out, because they add names
to the local namespace that are unknowable at compile time.
Therefore, if a function contains function definitions or
\keyword{lambda} expressions with free variables, the compiler will
flag this by raising a \exception{SyntaxError} exception.

To make the preceding explanation a bit clearer, here's an example:

\begin{verbatim}
x = 1
def f():
    # The next line is a syntax error
    exec 'x=2'  
    def g():
        return x
\end{verbatim}

Line 4 containing the \keyword{exec} statement is a syntax error,
since \keyword{exec} would define a new local variable named \samp{x}
whose value should be accessed by \function{g()}.  

This shouldn't be much of a limitation, since \keyword{exec} is rarely
used in most Python code (and when it is used, it's often a sign of a
poor design anyway).

Compatibility concerns have led to nested scopes being introduced
gradually; in Python 2.1, they aren't enabled by default, but can be
turned on within a module by using a future statement as described in
PEP 236.  (See the following section for further discussion of PEP
236.)  In Python 2.2, nested scopes will become the default and there
will be no way to turn them off, but users will have had all of 2.1's
lifetime to fix any breakage resulting from their introduction.

\begin{seealso}

\seepep{227}{Statically Nested Scopes}{Written and implemented by
Jeremy Hylton.}

\end{seealso}


%======================================================================
\section{PEP 236: __future__ Directives}

The reaction to nested scopes was widespread concern about the dangers
of breaking code with the 2.1 release, and it was strong enough to
make the Pythoneers take a more conservative approach.  This approach
consists of introducing a convention for enabling optional
functionality in release N that will become compulsory in release N+1.  

The syntax uses a \code{from...import} statement using the reserved
module name \module{__future__}.  Nested scopes can be enabled by the
following statement:

\begin{verbatim}
from __future__ import nested_scopes
\end{verbatim}

While it looks like a normal \keyword{import} statement, it's not;
there are strict rules on where such a future statement can be put.
They can only be at the top of a module, and must precede any Python
code or regular \keyword{import} statements.  This is because such
statements can affect how the Python bytecode compiler parses code and
generates bytecode, so they must precede any statement that will
result in bytecodes being produced.

\begin{seealso}

\seepep{236}{Back to the \module{__future__}}{Written by Tim Peters,
and primarily implemented by Jeremy Hylton.}

\end{seealso}

%======================================================================
\section{PEP 207: Rich Comparisons}

In earlier versions, Python's support for implementing comparisons on
user-defined classes and extension types was quite simple. Classes
could implement a \method{__cmp__} method that was given two instances
of a class, and could only return 0 if they were equal or +1 or -1 if
they weren't; the method couldn't raise an exception or return
anything other than a Boolean value.  Users of Numeric Python often
found this model too weak and restrictive, because in the
number-crunching programs that numeric Python is used for, it would be
more useful to be able to perform elementwise comparisons of two
matrices, returning a matrix containing the results of a given
comparison for each element.  If the two matrices are of different
sizes, then the compare has to be able to raise an exception to signal
the error.

In Python 2.1, rich comparisons were added in order to support this
need.  Python classes can now individually overload each of the
\code{<}, \code{<=}, \code{>}, \code{>=}, \code{==}, and \code{!=}
operations.  The new magic method names are:

\begin{tableii}{c|l}{code}{Operation}{Method name}
  \lineii{<}{\method{__lt__}} \lineii{<=}{\method{__le__}}
  \lineii{>}{\method{__gt__}} \lineii{>=}{\method{__ge__}}
  \lineii{==}{\method{__eq__}} \lineii{!=}{\method{__ne__}}
  \end{tableii}

(The magic methods are named after the corresponding Fortran operators
\code{.LT.}. \code{.LE.}, \&c.  Numeric programmers are almost
certainly quite familar with these names and will find them easy to
remember.)
 
Each of these magic methods is of the form \code{\var{method}(self,
other)}, where \code{self} will be the object on the left-hand side of
the operator, while \code{other} will be the object on the right-hand
side.  For example, the expression \code{A < B} will cause
\code{A.__lt__(B)} to be called.

Each of these magic methods can return anything at all: a Boolean, a
matrix, a list, or any other Python object.  Alternatively they can
raise an exception if the comparison is impossible, inconsistent, or
otherwise meaningless.

The built-in \function{cmp(A,B)} function can use the rich comparison
machinery, and now accepts an optional argument specifying which
comparison operation to use; this is given as one of the strings
\code{"<"}, \code{"<="}, \code{">"}, \code{">="}, \code{"=="}, or
\code{"!="}.  If called without the optional third argument,
\function{cmp()} will only return -1, 0, or +1 as in previous versions
of Python; otherwise it will call the appropriate method and can
return any Python object.

There are also corresponding changes of interest to C programmers;
there's a new slot \code{tp_richcmp} in type objects and an API for
performing a given rich comparison.  I won't cover the C API here, but
will refer you to PEP 207, or to 2.1's C API documentation, for the
full list of related functions.

\begin{seealso}

\seepep{207}{Rich Comparisions}{Written by Guido van Rossum, heavily
based on earlier work by David Ascher, and implemented by Guido van
Rossum.}

\end{seealso}

%======================================================================
\section{PEP 230: Warning Framework}

Over its 10 years of existence, Python has accumulated a certain
number of obsolete modules and features along the way.  It's difficult
to know when a feature is safe to remove, since there's no way of
knowing how much code uses it --- perhaps no programs depend on the
feature, or perhaps many do.  To enable removing old features in a
more structured way, a warning framework was added.  When the Python
developers want to get rid of a feature, it will first trigger a
warning in the next version of Python.  The following Python version
can then drop the feature, and users will have had a full release
cycle to remove uses of the old feature.

Python 2.1 adds the warning framework to be used in this scheme.  It
adds a \module{warnings} module that provide functions to issue
warnings, and to filter out warnings that you don't want to be
displayed. Third-party modules can also use this framework to
deprecate old features that they no longer wish to support.

For example, in Python 2.1 the \module{regex} module is deprecated, so
importing it causes a warning to be printed:

\begin{verbatim}
>>> import regex
__main__:1: DeprecationWarning: the regex module
         is deprecated; please use the re module
>>>
\end{verbatim}

Warnings can be issued by calling the \function{warnings.warn}
function:

\begin{verbatim}
warnings.warn("feature X no longer supported")
\end{verbatim}

The first parameter is the warning message; an additional optional
parameters can be used to specify a particular warning category.

Filters can be added to disable certain warnings; a regular expression
pattern can be applied to the message or to the module name in order
to suppress a warning.  For example, you may have a program that uses
the \module{regex} module and not want to spare the time to convert it
to use the \module{re} module right now.  The warning can be
suppressed by calling

\begin{verbatim}
import warnings
warnings.filterwarnings(action = 'ignore',
                        message='.*regex module is deprecated',
                        category=DeprecationWarning,
                        module = '__main__')
\end{verbatim}

This adds a filter that will apply only to warnings of the class
\class{DeprecationWarning} triggered in the \module{__main__} module,
and applies a regular expression to only match the message about the
\module{regex} module being deprecated, and will cause such warnings
to be ignored.  Warnings can also be printed only once, printed every
time the offending code is executed, or turned into exceptions that
will cause the program to stop (unless the exceptions are caught in
the usual way, of course).

Functions were also added to Python's C API for issuing warnings;
refer to PEP 230 or to Python's API documentation for the details.

\begin{seealso} 

\seepep{5}{Guidelines for Language Evolution}{Written
by Paul Prescod, to specify procedures to be followed when removing
old features from Python.  The policy described in this PEP hasn't
been officially adopted, but the eventual policy probably won't be too
different from Prescod's proposal.}

\seepep{230}{Warning Framework}{Written and implemented by Guido van
Rossum.}

\end{seealso}
    
%======================================================================
\section{PEP 229: New Build System}

When compiling Python, the user had to go in and edit the
\file{Modules/Setup} file in order to enable various additional
modules; the default set is relatively small and limited to modules
that compile on most Unix platforms.  This means that on Unix
platforms with many more features, most notably Linux, Python
installations often don't contain all useful modules they could.

Python 2.0 added the Distutils, a set of modules for distributing and
installing extensions.  In Python 2.1, the Distutils are used to
compile much of the standard library of extension modules,
autodetecting which ones are supported on the current machine.  It's
hoped that this will make Python installations easier and more
featureful.

Instead of having to edit the \file{Modules/Setup} file in order to
enable modules, a \file{setup.py} script in the top directory of the
Python source distribution is run at build time, and attempts to
discover which modules can be enabled by examining the modules and
header files on the system.  If a module is configured in
\file{Modules/Setup}, the \file{setup.py} script won't attempt to
compile that module and will defer to the \file{Modules/Setup} file's
contents.  This provides a way to specific any strange command-line
flags or libraries that are required for a specific platform.

In another far-reaching change to the build mechanism, Neil
Schemenauer restructured things so Python now uses a single makefile
that isn't recursive, instead of makefiles in the top directory and in
each of the \file{Python/}, \file{Parser/}, \file{Objects/}, and
\file{Modules/} subdirectories.  This makes building Python faster
and also makes hacking the Makefiles clearer and simpler.

\begin{seealso} 

\seepep{229}{Using Distutils to Build Python}{Written
and implemented by A.M. Kuchling.}

\end{seealso}

%======================================================================
\section{PEP 205: Weak References}

Weak references, available through the \module{weakref} module, are a
minor but useful new data type in the Python programmer's toolbox.

Storing a reference to an object (say, in a dictionary or a list) has
the side effect of keeping that object alive forever.  There are a few
specific cases where this behaviour is undesirable, object caches
being the most common one, and another being circular references in
data structures such as trees.

For example, consider a memoizing function that caches the results of
another function \function{f(\var{x})} by storing the function's
argument and its result in a dictionary:

\begin{verbatim}
_cache = {}
def memoize(x):
    if _cache.has_key(x):
        return _cache[x]

    retval = f(x)

    # Cache the returned object
    _cache[x] = retval

    return retval
\end{verbatim}

This version works for simple things such as integers, but it has a
side effect; the \code{_cache} dictionary holds a reference to the
return values, so they'll never be deallocated until the Python
process exits and cleans up This isn't very noticeable for integers,
but if \function{f()} returns an object, or a data structure that
takes up a lot of memory, this can be a problem.

Weak references provide a way to implement a cache that won't keep
objects alive beyond their time.  If an object is only accessible
through weak references, the object will be deallocated and the weak
references will now indicate that the object it referred to no longer
exists.  A weak reference to an object \var{obj} is created by calling
\code{wr = weakref.ref(\var{obj})}.  The object being referred to is
returned by calling the weak reference as if it were a function:
\code{wr()}.  It will return the referenced object, or \code{None} if
the object no longer exists. 

This makes it possible to write a \function{memoize()} function whose
cache doesn't keep objects alive, by storing weak references in the
cache.

\begin{verbatim}
_cache = {}
def memoize(x):
    if _cache.has_key(x):
        obj = _cache[x]()
        # If weak reference object still exists,
        # return it
        if obj is not None: return obj
 
    retval = f(x)

    # Cache a weak reference
    _cache[x] = weakref.ref(retval)

    return retval
\end{verbatim}

The \module{weakref} module also allows creating proxy objects which
behave like weak references --- an object referenced only by proxy
objects is deallocated -- but instead of requiring an explicit call to
retrieve the object, the proxy transparently forwards all operations
to the object as long as the object still exists.  If the object is
deallocated, attempting to use a proxy will cause a
\exception{weakref.ReferenceError} exception to be raised.

\begin{verbatim}
proxy = weakref.proxy(obj)
proxy.attr   # Equivalent to obj.attr
proxy.meth() # Equivalent to obj.meth()
del obj
proxy.attr   # raises weakref.ReferenceError
\end{verbatim}

\begin{seealso}

\seepep{205}{Weak References}{Written and implemented by
Fred~L. Drake,~Jr.}

\end{seealso}

%======================================================================
\section{PEP 232: Function Attributes}

In Python 2.1, functions can now have arbitrary information attached
to them.  People were often using docstrings to hold information about
functions and methods, because the \code{__doc__} attribute was the
only way of attaching any information to a function.  For example, in
the Zope Web application server, functions are marked as safe for
public access by having a docstring, and in John Aycock's SPARK
parsing framework, docstrings hold parts of the BNF grammar to be
parsed.  This overloading is unfortunate, since docstrings are really
intended to hold a function's documentation; for example, it means you
can't properly document functions intended for private use in Zope.

Arbitrary attributes can now be set and retrieved on functions using the
regular Python syntax:

\begin{verbatim}
def f(): pass

f.publish = 1
f.secure = 1
f.grammar = "A ::= B (C D)*"
\end{verbatim}

The dictionary containing attributes can be accessed as the function's
\member{__dict__}. Unlike the \member{__dict__} attribute of class
instances, in functions you can actually assign a new dictionary to
\member{__dict__}, though the new value is restricted to a regular
Python dictionary; you \emph{can't} be tricky and set it to a
\class{UserDict} instance, or any other random object that behaves
like a mapping.

\begin{seealso}

\seepep{232}{Function Attributes}{Written and implemented by Barry
Warsaw.}

\end{seealso}


%======================================================================

\section{PEP 235: Importing Modules on Case-Insensitive Platforms}

Some operating systems have filesystems that are case-insensitive,
MacOS and Windows being the primary examples; on these systems, it's
impossible to distinguish the filenames \samp{FILE.PY} and
\samp{file.py}, even though they do store the file's name 
in its original case (they're case-preserving, too).

In Python 2.1, the \keyword{import} statement will work to simulate
case-sensitivity on case-insensitive platforms.  Python will now
search for the first case-sensitive match by default, raising an
\exception{ImportError} if no such file is found, so \code{import file}
will not import a module named \samp{FILE.PY}.  Case-insensitive
matching can be requested by setting the \envvar{PYTHONCASEOK} environment
variable before starting the Python interpreter.

%======================================================================
\section{PEP 217: Interactive Display Hook}

When using the Python interpreter interactively, the output of
commands is displayed using the built-in \function{repr()} function.
In Python 2.1, the variable \function{sys.displayhook} can be set to a
callable object which will be called instead of \function{repr()}.
For example, you can set it to a special pretty-printing function:

\begin{verbatim}
>>> # Create a recursive data structure
... L = [1,2,3]
>>> L.append(L)
>>> L # Show Python's default output
[1, 2, 3, [...]]
>>> # Use pprint.pprint() as the display function
... import sys, pprint
>>> sys.displayhook = pprint.pprint
>>> L
[1, 2, 3,  <Recursion on list with id=135143996>]
>>>
\end{verbatim}

\begin{seealso}

\seepep{217}{Display Hook for Interactive Use}{Written and implemented
by Moshe Zadka.}

\end{seealso}

%======================================================================
\section{PEP 208: New Coercion Model}

How numeric coercion is done at the C level was significantly
modified.  This will only affect the authors of C extensions to
Python, allowing them more flexibility in writing extension types that
support numeric operations.

Extension types can now set the type flag \code{Py_TPFLAGS_CHECKTYPES}
in their \code{PyTypeObject} structure to indicate that they support
the new coercion model.  In such extension types, the numeric slot
functions can no longer assume that they'll be passed two arguments of
the same type; instead they may be passed two arguments of differing
types, and can then perform their own internal coercion.  If the slot
function is passed a type it can't handle, it can indicate the failure
by returning a reference to the \code{Py_NotImplemented} singleton
value.  The numeric functions of the other type will then be tried,
and perhaps they can handle the operation; if the other type also
returns \code{Py_NotImplemented}, then a \exception{TypeError} will be
raised.  Numeric methods written in Python can also return
\code{Py_NotImplemented}, causing the interpreter to act as if the
method did not exist (perhaps raising a \exception{TypeError}, perhaps
trying another object's numeric methods).

\begin{seealso}

\seepep{208}{Reworking the Coercion Model}{Written and implemented by
Neil Schemenauer, heavily based upon earlier work by Marc-Andr\'e
Lemburg.  Read this to understand the fine points of how numeric
operations will now be processed at the C level.}

\end{seealso}

%======================================================================
\section{PEP 241: Metadata in Python Packages}

A common complaint from Python users is that there's no single catalog
of all the Python modules in existence.  T.~Middleton's Vaults of
Parnassus at \url{http://www.vex.net/parnassus/} are the largest
catalog of Python modules, but registering software at the Vaults is
optional, and many people don't bother.

As a first small step toward fixing the problem, Python software
packaged using the Distutils \command{sdist} command will include a
file named \file{PKG-INFO} containing information about the package
such as its name, version, and author (metadata, in cataloguing
terminology).  PEP 241 contains the full list of fields that can be
present in the \file{PKG-INFO} file.  As people began to package their
software using Python 2.1, more and more packages will include
metadata, making it possible to build automated cataloguing systems
and experiment with them.  With the result experience, perhaps it'll
be possible to design a really good catalog and then build support for
it into Python 2.2.  For example, the Distutils \command{sdist}
and \command{bdist_*} commands could support a \option{upload} option
that would automatically upload your package to a catalog server. 

You can start creating packages containing \file{PKG-INFO} even if
you're not using Python 2.1, since a new release of the Distutils will
be made for users of earlier Python versions.  Version 1.0.2 of the
Distutils includes the changes described in PEP 241, as well as
various bugfixes and enhancements.  It will be available from 
the Distutils SIG at \url{http://www.python.org/sigs/distutils-sig/}.

% XXX update when I actually release 1.0.2

\begin{seealso}

\seepep{241}{Metadata for Python Software Packages}{Written and
implemented by A.M. Kuchling.}

\seepep{243}{Module Repository Upload Mechanism}{Written by Sean
Reifschneider, this draft PEP describes a proposed mechanism for uploading 
Python packages to a central server.
}

\end{seealso}

%======================================================================
\section{New and Improved Modules}

\begin{itemize}

\item Ka-Ping Yee contributed two new modules: \module{inspect.py}, a
module for getting information about live Python code, and
\module{pydoc.py}, a module for interactively converting docstrings to
HTML or text.  As a bonus, \file{Tools/scripts/pydoc}, which is now
automatically installed, uses \module{pydoc.py} to display
documentation given a Python module, package, or class name.  For
example, \samp{pydoc xml.dom} displays the following:

\begin{verbatim}
Python Library Documentation: package xml.dom in xml
 
NAME
    xml.dom - W3C Document Object Model implementation for Python.
 
FILE
    /usr/local/lib/python2.1/xml/dom/__init__.pyc
 
DESCRIPTION
    The Python mapping of the Document Object Model is documented in the
    Python Library Reference in the section on the xml.dom package.
 
    This package contains the following modules:
      ...
\end{verbatim}

\file{pydoc} also includes a Tk-based interactive help browser.  
\file{pydoc} quickly becomes addictive; try it out!

\item Two different modules for unit testing were added to the
standard library.  The \module{doctest} module, contributed by Tim
Peters, provides a testing framework based on running embedded
examples in docstrings and comparing the results against the expected
output.  PyUnit, contributed by Steve Purcell, is a unit testing
framework inspired by JUnit, which was in turn an adaptation of Kent
Beck's Smalltalk testing framework.  See
\url{http://pyunit.sourceforge.net/} for more information about
PyUnit.

\item The \module{difflib} module contains a class,
\class{SequenceMatcher}, which compares two sequences and computes the
changes required to transform one sequence into the other.  For
example, this module can be used to write a tool similar to the Unix
\program{diff} program, and in fact the sample program
\file{Tools/scripts/ndiff.py} demonstrates how to write such a script.  

\item \module{curses.panel}, a wrapper for the panel library, part of
ncurses and of SYSV curses, was contributed by Thomas Gellekum.  The
panel library provides windows with the additional feature of depth.
Windows can be moved higher or lower in the depth ordering, and the
panel library figures out where panels overlap and which sections are
visible.

\item The PyXML package has gone through a few releases since Python
2.0, and Python 2.1 includes an updated version of the \module{xml}
package.  Some of the noteworthy changes include support for Expat 1.2
and later versions, the ability for Expat parsers to handle files in
any encoding supported by Python, and various bugfixes for SAX, DOM,
and the \module{minidom} module.

\item Ping also contributed another hook for handling uncaught
exceptions.  \function{sys.excepthook} can be set to a callable
object.  When an exception isn't caught by any
\keyword{try}...\keyword{except} blocks, the exception will be passed
to \function{sys.excepthook}, which can then do whatever it likes.  At
the Ninth Python Conference, Ping demonstrated an application for this
hook: printing an extended traceback that not only lists the stack
frames, but also lists the function arguments and the local variables
for each frame.  

\item Various functions in the \module{time} module, such as
\function{asctime()} and \function{localtime()}, require a floating
point argument containing the time in seconds since the epoch.  The
most common use of these functions is to work with the current time,
so the floating point argument has been made optional; when a value
isn't provided, the current time will be used.  For example, log file
entries usually need a string containing the current time; in Python
2.1, \code{time.asctime()} can be used, instead of the lengthier
\code{time.asctime(time.localtime(time.time()))} that was previously
required.
 
This change was proposed and implemented by Thomas Wouters.

\item The \module{ftplib} module now defaults to retrieving files in
passive mode, because passive mode is more likely to work from behind
a firewall.  This request came from the Debian bug tracking system,
since other Debian packages use \module{ftplib} to retrieve files and
then don't work from behind a firewall.  It's deemed unlikely that
this will cause problems for anyone, because Netscape defaults to
passive mode and few people complain, but if passive mode is
unsuitable for your application or network setup, call
\method{set_pasv(0)} on FTP objects to disable passive mode.

\item Support for raw socket access has been added to the
\module{socket} module, contributed by Grant Edwards.

\item The \module{pstats} module now contains a simple interactive
statistics browser for displaying timing profiles for Python programs,
invoked when the module is run as a script.  Contributed by 
Eric S.\ Raymond.

\item A new implementation-dependent function, \function{sys._getframe(\optional{depth})},
has been added to return a given frame object from the current call stack.
\function{sys._getframe()} returns the frame at the top of the call stack; 
if the optional integer argument \var{depth} is supplied, the function returns the frame
that is \var{depth} calls below the top of the stack.  For example, \code{sys._getframe(1)}
returns the caller's frame object.

This function is only present in CPython, not in Jython or the .NET
implementation.  Use it for debugging, and resist the temptation to
put it into production code.



\end{itemize}

%======================================================================
\section{Other Changes and Fixes}

There were relatively few smaller changes made in Python 2.1 due to
the shorter release cycle.  A search through the CVS change logs turns
up 117 patches applied, and 136 bugs fixed; both figures are likely to
be underestimates.  Some of the more notable changes are:

\begin{itemize}


\item A specialized object allocator is now optionally available, that
should be faster than the system \function{malloc()} and have less
memory overhead.  The allocator uses C's \function{malloc()} function
to get large pools of memory, and then fulfills smaller memory
requests from these pools.  It can be enabled by providing the
\longprogramopt{with-pymalloc} option to the \program{configure} script; see
\file{Objects/obmalloc.c} for the implementation details.  

Authors of C extension modules should test their code with the object
allocator enabled, because some incorrect code may break, causing core
dumps at runtime.  There are a bunch of memory allocation functions in
Python's C API that have previously been just aliases for the C
library's \function{malloc()} and \function{free()}, meaning that if
you accidentally called mismatched functions, the error wouldn't be
noticeable.  When the object allocator is enabled, these functions
aren't aliases of \function{malloc()} and \function{free()} any more,
and calling the wrong function to free memory will get you a core
dump.  For example, if memory was allocated using
\function{PyMem_New()}, it has to be freed using
\function{PyMem_Del()}, not \function{free()}.  A few modules included
with Python fell afoul of this and had to be fixed; doubtless there
are more third-party modules that will have the same problem.

The object allocator was contributed by Vladimir Marangozov.

\item The speed of line-oriented file I/O has been improved because
people often complain about its lack of speed, and because it's often
been used as a na\"ive benchmark.  The \method{readline()} method of
file objects has therefore been rewritten to be much faster.  The
exact amount of the speedup will vary from platform to platform
depending on how slow the C library's \function{getc()} was, but is
around 66\%, and potentially much faster on some particular operating
systems.  Tim Peters did much of the benchmarking and coding for this
change, motivated by a discussion in comp.lang.python.

A new module and method for file objects was also added, contributed
by Jeff Epler. The new method, \method{xreadlines()}, is similar to
the existing \function{xrange()} built-in.  \function{xreadlines()}
returns an opaque sequence object that only supports being iterated
over, reading a line on every iteration but not reading the entire
file into memory as the existing \method{readlines()} method does.
You'd use it like this:

\begin{verbatim}
for line in sys.stdin.xreadlines():
    # ... do something for each line ...
    ...
\end{verbatim}

For a fuller discussion of the line I/O changes, see the python-dev
summary for January 1-15, 2001 at
\url{http://www.python.org/dev/summary/2001-01-1.html}.

\item A new method, \method{popitem()}, was added to dictionaries to
enable destructively iterating through the contents of a dictionary;
this can be faster for large dictionaries because there's no need to
construct a list containing all the keys or values.
\code{D.popitem()} removes a random \code{(\var{key}, \var{value})}
pair from the dictionary~\code{D} and returns it as a 2-tuple.  This
was implemented mostly by Tim Peters and Guido van Rossum, after a
suggestion and preliminary patch by Moshe Zadka.
 
\item Modules can now control which names are imported when \code{from
\var{module} import *} is used, by defining an \code{__all__}
attribute containing a list of names that will be imported.  One
common complaint is that if the module imports other modules such as
\module{sys} or \module{string}, \code{from \var{module} import *}
will add them to the importing module's namespace.  To fix this,
simply list the public names in \code{__all__}:

\begin{verbatim}
# List public names
__all__ = ['Database', 'open']
\end{verbatim}

A stricter version of this patch was first suggested and implemented
by Ben Wolfson, but after some python-dev discussion, a weaker final
version was checked in.

\item Applying \function{repr()} to strings previously used octal
escapes for non-printable characters; for example, a newline was
\code{'\e 012'}.  This was a vestigial trace of Python's C ancestry, but
today octal is of very little practical use.  Ka-Ping Yee suggested
using hex escapes instead of octal ones, and using the \code{\e n},
\code{\e t}, \code{\e r} escapes for the appropriate characters, and
implemented this new formatting.

\item Syntax errors detected at compile-time can now raise exceptions
containing the filename and line number of the error, a pleasant side
effect of the compiler reorganization done by Jeremy Hylton.

\item C extensions which import other modules have been changed to use
\function{PyImport_ImportModule()}, which means that they will use any
import hooks that have been installed.  This is also encouraged for
third-party extensions that need to import some other module from C
code.  

\item The size of the Unicode character database was shrunk by another
340K thanks to Fredrik Lundh.

\item Some new ports were contributed: MacOS X (by Steven Majewski),
Cygwin (by Jason Tishler); RISCOS (by Dietmar Schwertberger); Unixware~7 
(by Billy G. Allie).

\end{itemize}

And there's the usual list of minor bugfixes, minor memory leaks,
docstring edits, and other tweaks, too lengthy to be worth itemizing;
see the CVS logs for the full details if you want them.


%======================================================================
\section{Acknowledgements}

The author would like to thank the following people for offering
suggestions on various drafts of this article: Graeme Cross, David
Goodger, Jay Graves, Michael Hudson, Marc-Andr\'e Lemburg, Fredrik
Lundh, Neil Schemenauer, Thomas Wouters.

\end{document}

--- NEW FILE: whatsnew23.tex ---
\documentclass{howto}
\usepackage{distutils}
% $Id: whatsnew23.tex,v 1.1 2004/05/01 00:54:02 tismer Exp $

\title{What's New in Python 2.3}
\release{1.01}
\author{A.M.\ Kuchling}
\authoraddress{
	\strong{Python Software Foundation}\\
	Email: \email{amk at amk.ca}
}

\begin{document}
\maketitle
\tableofcontents

This article explains the new features in Python 2.3.  Python 2.3 was
released on July 29, 2003.

[...2339 lines suppressed...]
name.

\end{itemize}


%======================================================================
\section{Acknowledgements \label{acks}}

The author would like to thank the following people for offering
suggestions, corrections and assistance with various drafts of this
article: Jeff Bauer, Simon Brunning, Brett Cannon, Michael Chermside,
Andrew Dalke, Scott David Daniels, Fred~L. Drake, Jr., David Fraser, 
Kelly Gerber,
Raymond Hettinger, Michael Hudson, Chris Lambert, Detlef Lannert,
Martin von~L\"owis, Andrew MacIntyre, Lalo Martins, Chad Netzer,
Gustavo Niemeyer, Neal Norwitz, Hans Nowak, Chris Reedy, Francesco
Ricciardi, Vinay Sajip, Neil Schemenauer, Roman Suzi, Jason Tishler,
Just van~Rossum.

\end{document}

--- NEW FILE: whatsnew24.tex ---
\documentclass{howto}
\usepackage{distutils}
% $Id: whatsnew24.tex,v 1.1 2004/05/01 00:54:02 tismer Exp $

\title{What's New in Python 2.4}
\release{0.0}
\author{A.M.\ Kuchling}
\authoraddress{
	\strong{Python Software Foundation}\\
	Email: \email{amk at amk.ca}
}

\begin{document}
\maketitle
\tableofcontents

This article explains the new features in Python 2.4.  No release date
for Python 2.4 has been set; expect that this will happen mid-2004.

While Python 2.3 was primarily a library development release, Python
2.4 may extend the core language and interpreter in
as-yet-undetermined ways.

This article doesn't attempt to provide a complete specification of
the new features, but instead provides a convenient overview.  For
full details, you should refer to the documentation for Python 2.4,
such as the \citetitle[../lib/lib.html]{Python Library Reference} and
the \citetitle[../ref/ref.html]{Python Reference Manual}.  
If you want to understand the complete implementation and design
rationale, refer to the PEP for a particular new feature.


%======================================================================
\section{PEP 218: Built-In Set Objects}

Two new built-in types, \function{set(iterable)} and
\function{frozenset(iterable)} provide high speed data types for
membership testing, for eliminating duplicates from sequences, and
for mathematical operations like unions, intersections, differences,
and symmetric differences.  

\begin{verbatim}
>>> a = set('abracadabra')              # form a set from a string
>>> 'z' in a                            # fast membership testing
False
>>> a                                   # unique letters in a
set(['a', 'r', 'b', 'c', 'd'])
>>> ''.join(a)                          # convert back into a string
'arbcd'

>>> b = set('alacazam')                 # form a second set
>>> a - b                               # letters in a but not in b
set(['r', 'd', 'b'])
>>> a | b                               # letters in either a or b
set(['a', 'c', 'r', 'd', 'b', 'm', 'z', 'l'])
>>> a & b                               # letters in both a and b
set(['a', 'c'])
>>> a ^ b                               # letters in a or b but not both
set(['r', 'd', 'b', 'm', 'z', 'l'])

>>> a.add('z')                          # add a new element
>>> a.update('wxy')                     # add multiple new elements
>>> a
set(['a', 'c', 'b', 'd', 'r', 'w', 'y', 'x', 'z'])       
>>> a.remove('x')                       # take one element out
>>> a
set(['a', 'c', 'b', 'd', 'r', 'w', 'y', 'z'])       
\end{verbatim}

The type \function{frozenset()} is an immutable version of \function{set()}.
Since it is immutable and hashable, it may be used as a dictionary key or
as a member of another set.  Accordingly, it does not have methods
like \method{add()} and \method{remove()} which could alter its contents.

% XXX what happens to the sets module?
% The current thinking is that the sets module will be left alone.
% That way, existing code will continue to run without alteration.
% Also, the module provides an autoconversion feature not supported by set()
% and frozenset().

\begin{seealso}
\seepep{218}{Adding a Built-In Set Object Type}{Originally proposed by
Greg Wilson and ultimately implemented by Raymond Hettinger.}
\end{seealso}

%======================================================================
\section{PEP 237: Unifying Long Integers and Integers}

XXX write this.

%======================================================================
\section{PEP 322: Reverse Iteration}

A new built-in function, \function{reversed(seq)}, takes a sequence
and returns an iterator that returns the elements of the sequence 
in reverse order.  

\begin{verbatim}
>>> for i in reversed(xrange(1,4)):
...    print i
... 
3
2
1
\end{verbatim}

Compared to extended slicing, \code{range(1,4)[::-1]}, \function{reversed()}
is easier to read, runs faster, and uses substantially less memory.

Note that \function{reversed()} only accepts sequences, not arbitrary
iterators.  If you want to reverse an iterator, first convert it to 
a list with \function{list()}.

\begin{verbatim}
>>> input= open('/etc/passwd', 'r')
>>> for line in reversed(list(input)):
...   print line
... 
root:*:0:0:System Administrator:/var/root:/bin/tcsh
  ...
\end{verbatim}

\begin{seealso}
\seepep{322}{Reverse Iteration}{Written and implemented by Raymond Hettinger.}

\end{seealso}


%======================================================================
\section{Other Language Changes}

Here are all of the changes that Python 2.4 makes to the core Python
language.

\begin{itemize}

\item The \method{dict.update()} method now accepts the same
argument forms as the \class{dict} constructor.  This includes any
mapping, any iterable of key/value pairs, and/or keyword arguments.       

\item The string methods, \method{ljust()}, \method{rjust()}, and
\method{center()} now take an optional argument for specifying a
fill character other than a space.

\item Strings also gained an \method{rsplit()} method that
works like the \method{split()} method but splits from the end of
the string.  

\begin{verbatim}
>>> 'www.python.org'.split('.', 1)
['www', 'python.org']
'www.python.org'.rsplit('.', 1)
['www.python', 'org']        
\end{verbatim}      

\item The \method{sort()} method of lists gained three keyword
arguments, \var{cmp}, \var{key}, and \var{reverse}.  These arguments
make some common usages of \method{sort()} simpler.  All are optional.

\var{cmp} is the same as the previous single argument to
\method{sort()}; if provided, the value should be a comparison
function that takes two arguments and returns -1, 0, or +1 depending
on how the arguments compare.  

\var{key} should be a single-argument function that takes a list
element and returns a comparison key for the element.  The list is
then sorted using the comparison keys.  The following example sorts a
list case-insensitively:

\begin{verbatim}
>>> L = ['A', 'b', 'c', 'D']
>>> L.sort()                 # Case-sensitive sort
>>> L
['A', 'D', 'b', 'c']
>>> L.sort(key=lambda x: x.lower())
>>> L
['A', 'b', 'c', 'D']
>>> L.sort(cmp=lambda x,y: cmp(x.lower(), y.lower()))
>>> L
['A', 'b', 'c', 'D']
\end{verbatim}

The last example, which uses the \var{cmp} parameter, is the old way
to perform a case-insensitive sort.  It works but is slower than
using a \var{key} parameter.  Using \var{key} results in calling the
\method{lower()} method once for each element in the list while using
\var{cmp} will call the method twice for each comparison.

For simple key functions and comparison functions, it is often
possible to avoid a \keyword{lambda} expression by using an unbound
method instead.  For example, the above case-insensitive sort is best
coded as:

\begin{verbatim}
>>> L.sort(key=str.lower)
>>> L
['A', 'b', 'c', 'D']
\end{verbatim}       

The \var{reverse} parameter should have a Boolean value.  If the value is
\constant{True}, the list will be sorted into reverse order.  Instead
of \code{L.sort(lambda x,y: cmp(y.score, x.score))}, you can now write:
\code{L.sort(key = lambda x: x.score, reverse=True)}.

The results of sorting are now guaranteed to be stable.  This means
that two entries with equal keys will be returned in the same order as
they were input.  For example, you can sort a list of people by name,
and then sort the list by age, resulting in a list sorted by age where
people with the same age are in name-sorted order.

\item There is a new built-in function \function{sorted(iterable)} that works
like the in-place \method{list.sort()} method but has been made suitable
for use in expressions.  The differences are:
  \begin{itemize}
  \item the input may be any iterable;
  \item a newly formed copy is sorted, leaving the original intact; and
  \item the expression returns the new sorted copy
  \end{itemize}

\begin{verbatim}
>>> L = [9,7,8,3,2,4,1,6,5]
>>> [10+i for i in sorted(L)]       # usable in a list comprehension
[11, 12, 13, 14, 15, 16, 17, 18, 19]
>>> L = [9,7,8,3,2,4,1,6,5]         # original is left unchanged
[9,7,8,3,2,4,1,6,5]   

>>> sorted('Monte Python')          # any iterable may be an input
[' ', 'M', 'P', 'e', 'h', 'n', 'n', 'o', 'o', 't', 't', 'y']

>>> # List the contents of a dict sorted by key values
>>> colormap = dict(red=1, blue=2, green=3, black=4, yellow=5)
>>> for k, v in sorted(colormap.iteritems()):
...     print k, v
...
black 4
blue 2
green 3
red 1
yellow 5

\end{verbatim}

\item The \function{zip()} built-in function and \function{itertools.izip()}
  now return an empty list instead of raising a \exception{TypeError}
  exception if called with no arguments.  This makes them more
  suitable for use with variable length argument lists:

\begin{verbatim}
>>> def transpose(array):
...    return zip(*array)
...
>>> transpose([(1,2,3), (4,5,6)])
[(1, 4), (2, 5), (3, 6)]
>>> transpose([])
[]
\end{verbatim}

\end{itemize}


%======================================================================
\subsection{Optimizations}

\begin{itemize}

\item The inner loops for \class{list} and \class{tuple} slicing
 were optimized and now run about one-third faster.  The inner
 loops were also optimized for \class{dict} with performance
 boosts to \method{keys()}, \method{values()}, \method{items()},
\method{iterkeys()}, \method{itervalues()}, and \method{iteritems()}.

\item The machinery for growing and shrinking lists was optimized
 for speed and for space efficiency.  Small lists (under eight elements)
 never over-allocate by more than three elements.  Large lists do not
 over-allocate by more than 1/8th.  Appending and popping from lists
 now runs faster due to more efficient code paths and less frequent
 use of the underlying system realloc().  List comprehensions also
 benefit.  The amount of improvement varies between systems and shows
 the greatest improvement on systems with poor realloc() implementations.
 \method{list.extend()} was also optimized and no longer converts its
 argument into a temporary list prior to extending the base list.

\item \function{list()}, \function{tuple()}, \function{map()},
  \function{filter()}, and \function{zip()} now run several times
  faster with non-sequence arguments that supply a \method{__len__()}
  method.  Previously, the pre-sizing optimization only applied to
  sequence arguments.

\item The methods \method{list.__getitem__()},
  \method{dict.__getitem__()}, and \method{dict.__contains__()} are
  are now implemented as \class{method_descriptor} objects rather
  than \class{wrapper_descriptor} objects.  This form of optimized
  access doubles their performance and makes them more suitable for
  use as arguments to functionals:
  \samp{map(mydict.__getitem__, keylist)}.

\item Added an newcode opcode, \code{LIST_APPEND}, that simplifies
  the generated bytecode for list comprehensions and speeds them up
  by about a third.

\end{itemize}

The net result of the 2.4 optimizations is that Python 2.4 runs the
pystone benchmark around XX\% faster than Python 2.3 and YY\% faster
than Python 2.2.


%======================================================================
\section{New, Improved, and Deprecated Modules}

As usual, Python's standard library received a number of enhancements and
bug fixes.  Here's a partial list of the most notable changes, sorted
alphabetically by module name. Consult the
\file{Misc/NEWS} file in the source tree for a more
complete list of changes, or look through the CVS logs for all the
details.

\begin{itemize}

\item The \module{curses} modules now supports the ncurses extension 
   \function{use_default_colors()}.   On platforms where the terminal 
   supports transparency, this makes it possible to use a transparent background.
   (Contributed by J\"org Lehmann.)

\item The \module{bisect} module now has an underlying C implementation
   for improved performance.
   (Contributed by Dmitry Vasiliev.)

\item The CJKCodecs collections of East Asian codecs, maintained
by Hye-Shik Chang, was integrated into 2.4.  
The new encodings are:

\begin{itemize}
 \item Chinese (PRC): gb2312, gbk, gb18030, hz
 \item Chinese (ROC): big5, cp950
 \item Japanese: cp932, shift-jis, shift-jisx0213, euc-jp,
euc-jisx0213, iso-2022-jp, iso-2022-jp-1, iso-2022-jp-2,
 iso-2022-jp-3, iso-2022-jp-ext
 \item Korean: cp949, euc-kr, johab, iso-2022-kr
\end{itemize} 

\item There is a new \module{collections} module for 
   various specialized collection datatypes.  
   Currently it contains just one type, \class{deque}, 
   a double-ended queue that supports efficiently adding and removing
   elements from either end.

\begin{verbatim}
>>> from collections import deque
>>> d = deque('ghi')        # make a new deque with three items
>>> d.append('j')           # add a new entry to the right side
>>> d.appendleft('f')       # add a new entry to the left side
>>> d                       # show the representation of the deque
deque(['f', 'g', 'h', 'i', 'j'])
>>> d.pop()                 # return and remove the rightmost item
'j'
>>> d.popleft()             # return and remove the leftmost item
'f'
>>> list(d)                 # list the contents of the deque
['g', 'h', 'i']
>>> 'h' in d                # search the deque
True  
\end{verbatim}

Several modules now take advantage of \class{collections.deque} for
improved performance:  \module{Queue}, \module{mutex}, \module{shlex}
\module{threading}, and \module{pydoc}.

\item The \module{heapq} module has been converted to C.  The resulting
   tenfold improvement in speed makes the module suitable for handling
   high volumes of data.

\item The \module{imaplib} module now supports IMAP's THREAD command.
(Contributed by Yves Dionne.)

\item The \module{itertools} module gained a
  \function{groupby(\var{iterable}\optional{, \var{func}})} function,
  inspired by the GROUP BY clause from SQL.
  \var{iterable} returns a succession of elements, and the optional
  \var{func} is a function that takes an element and returns a key
  value; if omitted, the key is simply the element itself.
  \function{groupby()} then groups the elements into subsequences
  which have matching values of the key, and returns a series of 2-tuples
  containing the key value and an iterator over the subsequence.
 
Here's an example.  The \var{key} function simply returns whether a
number is even or odd, so the result of \function{groupby()} is to
return consecutive runs of odd or even numbers.

\begin{verbatim}
>>> import itertools
>>> L = [2,4,6, 7,8,9,11, 12, 14]
>>> for key_val, it in itertools.groupby(L, lambda x: x % 2):
...    print key_val, list(it)
... 
0 [2, 4, 6]
1 [7]
0 [8]
1 [9, 11]
0 [12, 14]
>>> 
\end{verbatim}

Like its SQL counterpart, \function{groupby()} is typically used with
sorted input.  The logic for \function{groupby()} is similar to the
\UNIX{} \code{uniq} filter which makes it handy for eliminating,
counting, or identifying duplicate elements:

\begin{verbatim}
>>> word = 'abracadabra'
>>> letters = sorted(word)   # Turn string into a sorted list of letters
>>> letters 
['a', 'a', 'a', 'a', 'a', 'b', 'b', 'c', 'd', 'r', 'r']
>>> [k for k, g in groupby(letters)]                     # List unique letters
['a', 'b', 'c', 'd', 'r']
>>> [(k, len(list(g))) for k, g in groupby(letters)]     # Count letter occurences
[('a', 5), ('b', 2), ('c', 1), ('d', 1), ('r', 2)]
>>> [k for k, g in groupby(letters) if len(list(g)) > 1] # List duplicated letters
['a', 'b', 'r']
\end{verbatim}

\item \module{itertools} also gained a function named
\function{tee(\var{iterator}, \var{N})} that returns \var{N} independent
iterators that replicate \var{iterator}.  If \var{N} is omitted, the
default is 2.

\begin{verbatim}
>>> L = [1,2,3]
>>> i1, i2 = itertools.tee(L)
>>> i1,i2
(<itertools.tee object at 0x402c2080>, <itertools.tee object at 0x402c2090>)
>>> list(i1)               # Run the first iterator to exhaustion
[1, 2, 3]
>>> list(i2)               # Run the second iterator to exhaustion
[1, 2, 3]
>\end{verbatim}

Note that \function{tee()} has to keep copies of the values returned 
by the iterator; in the worst case, it may need to keep all of them.  
This should therefore be used carefully if the leading iterator
can run far ahead of the trailing iterator in a long stream of inputs.
If the separation is large, then it becomes preferable to use
\function{list()} instead.  When the iterators track closely with one
another, \function{tee()} is ideal.  Possible applications include
bookmarking, windowing, or lookahead iterators.

\item A new \function{getsid()} function was added to the
\module{posix} module that underlies the \module{os} module.
(Contributed by J. Raynor.)

\item The \module{operator} module gained two new functions, 
\function{attrgetter(\var{attr})} and \function{itemgetter(\var{index})}.
Both functions return callables that take a single argument and return
the corresponding attribute or item; these callables make excellent
data extractors when used with \function{map()} or \function{sorted()}.
For example:

\begin{verbatim}
>>> L = [('c', 2), ('d', 1), ('a', 4), ('b', 3)]
>>> map(operator.itemgetter(0), L)
['c', 'd', 'a', 'b']
>>> map(operator.itemgetter(1), L)
[2, 1, 4, 3]
>>> sorted(L, key=operator.itemgetter(1)) # Sort list by second tuple item
[('d', 1), ('c', 2), ('b', 3), ('a', 4)]
\end{verbatim}

\item The \module{random} module has a new method called \method{getrandbits(N)} 
   which returns an N-bit long integer.  This method supports the existing
   \method{randrange()} method, making it possible to efficiently generate
   arbitrarily large random numbers.

\item The regular expression language accepted by the \module{re} module
   was extended with simple conditional expressions, written as
   \code{(?(\var{group})\var{A}|\var{B})}.  \var{group} is either a
   numeric group ID or a group name defined with \code{(?P<group>...)} 
   earlier in the expression.  If the specified group matched, the
   regular expression pattern \var{A} will be tested against the string; if
   the group didn't match, the pattern \var{B} will be used instead.
   
\end{itemize}


%======================================================================
% whole new modules get described in \subsections here


% ======================================================================
\section{Build and C API Changes}

Changes to Python's build process and to the C API include:

\begin{itemize}

  \item Three new convenience macros were added for common return
  values from extension functions: \csimplemacro{Py_RETURN_NONE},
  \csimplemacro{Py_RETURN_TRUE}, and \csimplemacro{Py_RETURN_FALSE}.

  \item A new function, \cfunction{PyTuple_Pack(\var{N}, \var{obj1},
  \var{obj2}, ..., \var{objN})}, constructs tuples from a variable
  length argument list of Python objects.

  \item A new function, \cfunction{PyDict_Contains(\var{d}, \var{k})},
  implements fast dictionary lookups without masking exceptions raised
  during the look-up process.

  \item A new method flag, \constant{METH_COEXISTS}, allows a function
  defined in slots to co-exist with a PyCFunction having the same name.
  This can halve the access to time to a method such as
  \method{set.__contains__()}

\end{itemize}


%======================================================================
\subsection{Port-Specific Changes}

\begin{itemize}

\item The Windows port now builds under MSVC++ 7.1 as well as version 6.

\end{itemize}


%======================================================================
\section{Other Changes and Fixes \label{section-other}}

As usual, there were a bunch of other improvements and bugfixes
scattered throughout the source tree.  A search through the CVS change
logs finds there were XXX patches applied and YYY bugs fixed between
Python 2.3 and 2.4.  Both figures are likely to be underestimates.

Some of the more notable changes are:

\begin{itemize}

\item The \module{timeit} module now automatically disables periodic
  garbarge collection during the timing loop.  This change makes
  consecutive timings more comparable.

\item The \module{base64} module now has more complete RFC 3548 support
  for Base64, Base32, and Base16 encoding and decoding, including
  optional case folding and optional alternative alphabets.
  (Contributed by Barry Warsaw.)

\end{itemize}


%======================================================================
\section{Porting to Python 2.4}

This section lists previously described changes that may require
changes to your code:

\begin{itemize}

\item The \function{zip()} built-in function and \function{itertools.izip()}
  now return  an empty list instead of raising a \exception{TypeError}
  exception if called with no arguments.

\item \function{dircache.listdir()} now passes exceptions to the caller
      instead of returning empty lists.

\end{itemize}


%======================================================================
\section{Acknowledgements \label{acks}}

The author would like to thank the following people for offering
suggestions, corrections and assistance with various drafts of this
article: Raymond Hettinger.

\end{document}


_______________________________________________
Stackless-checkins mailing list
Stackless-checkins at stackless.com
http://www.stackless.com/mailman/listinfo/stackless-checkins



More information about the Stackless-checkins mailing list