Delete the LaTeX doc tree.

1 files changed, 0 insertions, 868 deletions

diff --git a/Doc/whatsnew/whatsnew21.tex b/Doc/whatsnew/whatsnew21.tex
deleted file mode 100644
index 67cbbe4..0000000
--- a/Doc/whatsnew/whatsnew21.tex
+++ /dev/null
@@ -1,868 +0,0 @@
-\documentclass{howto}
-
-\usepackage{distutils}
-
-% $Id$
-
-\title{What's New in Python 2.1}
-\release{1.01}
-\author{A.M. Kuchling}
-\authoraddress{
-	\strong{Python Software Foundation}\\
-	Email: \email{amk@amk.ca}
-}
-\begin{document}
-\maketitle\tableofcontents
-
-\section{Introduction}
-
-This article explains the new features in Python 2.1.  While there aren't as
-many changes in 2.1 as there were in Python 2.0, there are still some
-pleasant surprises in store.  2.1 is the first release to be steered
-through the use of Python Enhancement Proposals, or PEPs, so most of
-the sizable changes have accompanying PEPs that provide more complete
-documentation and a design rationale for the change.  This article
-doesn't attempt to document the new features completely, but simply
-provides an overview of the new features for Python programmers.
-Refer to the Python 2.1 documentation, or to the specific PEP, for
-more details about any new feature that particularly interests you.
-
-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.
-
-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 familiar 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/}.
-
-\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}