source: trunk/essentials/dev-lang/python/Doc/whatsnew/whatsnew21.tex

\documentclass{howto}

\usepackage{distutils}

% $Id: whatsnew21.tex 50964 2006-07-30 03:03:43Z fred.drake $

\title{What's New in Python 2.1}
\release{1.01}
\author{A.M. Kuchling}
\authoraddress{
        \strong{Python Software Foundation}\\
        Email: \email{[email protected]}
}
\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