Commit 5e08a01a authored by Andrew M. Kuchling's avatar Andrew M. Kuchling

Various corrections pointed out by Detlef Lannert

parent f2eac99a
\documentclass{howto} \documentclass{howto}
\title{What's New in Python 2.0} \title{What's New in Python 2.0}
\release{0.04} \release{0.05}
\author{A.M. Kuchling and Moshe Zadka} \author{A.M. Kuchling and Moshe Zadka}
\authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} } \authoraddress{\email{amk1@bigfoot.com}, \email{moshez@math.huji.ac.il} }
\begin{document} \begin{document}
...@@ -81,8 +81,8 @@ long, containing the character \var{ch}. ...@@ -81,8 +81,8 @@ long, containing the character \var{ch}.
\item \code{ord(\var{u})}, where \var{u} is a 1-character regular or Unicode string, returns the number of the character as an integer. \item \code{ord(\var{u})}, where \var{u} is a 1-character regular or Unicode string, returns the number of the character as an integer.
\item \code{unicode(\var{string}, \optional{\var{encoding},} \item \code{unicode(\var{string} \optional{, \var{encoding}}
\optional{\var{errors}} ) } creates a Unicode string from an 8-bit \optional{, \var{errors}} ) } creates a Unicode string from an 8-bit
string. \code{encoding} is a string naming the encoding to use. string. \code{encoding} is a string naming the encoding to use.
The \code{errors} parameter specifies the treatment of characters that The \code{errors} parameter specifies the treatment of characters that
are invalid for the current encoding; passing \code{'strict'} as the are invalid for the current encoding; passing \code{'strict'} as the
...@@ -151,7 +151,7 @@ output.close() ...@@ -151,7 +151,7 @@ output.close()
The following code would then read UTF-8 input from the file: The following code would then read UTF-8 input from the file:
\begin{verbatim} \begin{verbatim}
input = UTF8_streamread( open( '/tmp/output', 'rb') ) input = UTF8_streamreader( open( '/tmp/output', 'rb') )
print repr(input.read()) print repr(input.read())
input.close() input.close()
\end{verbatim} \end{verbatim}
...@@ -272,11 +272,10 @@ up-to-date by Skip Montanaro. ...@@ -272,11 +272,10 @@ up-to-date by Skip Montanaro.
\section{Augmented Assignment} \section{Augmented Assignment}
Augmented assignment operators, another long-requested feature, have Augmented assignment operators, another long-requested feature, have
been added to Python 2.0. Augmented assignment operators include been added to Python 2.0. Augmented assignment operators include
\code{+=}, \code{-=}, \code{*=}, and so forth. For example, the \code{+=}, \code{-=}, \code{*=}, and so forth. For example, the
statement \code{a += 2} increments the value of the variable \code{a} statement \code{a += 2} increments the value of the variable
by 2, equivalent to the slightly lengthier \code{a} by 2, equivalent to the slightly lengthier \code{a = a + 2}.
\code{a = a + 2}.
The full list of supported assignment operators is \code{+=}, The full list of supported assignment operators is \code{+=},
\code{-=}, \code{*=}, \code{/=}, \code{\%=}, \code{**=}, \code{\&=}, \code{-=}, \code{*=}, \code{/=}, \code{\%=}, \code{**=}, \code{\&=},
...@@ -312,7 +311,7 @@ assignment patch was implemented by Thomas Wouters. ...@@ -312,7 +311,7 @@ assignment patch was implemented by Thomas Wouters.
\section{String Methods} \section{String Methods}
Until now string-manipulation functionality was in the \module{string} Until now string-manipulation functionality was in the \module{string}
Python module, which was usually a front-end for the \module{strop} module, which was usually a front-end for the \module{strop}
module written in C. The addition of Unicode posed a difficulty for module written in C. The addition of Unicode posed a difficulty for
the \module{strop} module, because the functions would all need to be the \module{strop} module, because the functions would all need to be
rewritten in order to accept either 8-bit or Unicode strings. For rewritten in order to accept either 8-bit or Unicode strings. For
...@@ -445,12 +444,12 @@ def f(*args, **kw): ...@@ -445,12 +444,12 @@ def f(*args, **kw):
\end{verbatim} \end{verbatim}
The \keyword{print} statement can now have its output directed to a The \keyword{print} statement can now have its output directed to a
file-like object by following the \keyword{print} with \code{>> file-like object by following the \keyword{print} with
\var{fileobj}}, similar to the redirection operator in Unix shells. \verb|>> file|, similar to the redirection operator in Unix shells.
Previously you'd either have to use the \method{write()} method of the Previously you'd either have to use the \method{write()} method of the
file-like object, which lacks the convenience and simplicity of file-like object, which lacks the convenience and simplicity of
\keyword{print}, or you could assign a new value to \code{sys.stdout} \keyword{print}, or you could assign a new value to
and then restore the old value. For sending output to standard error, \code{sys.stdout} and then restore the old value. For sending output to standard error,
it's much easier to write this: it's much easier to write this:
\begin{verbatim} \begin{verbatim}
...@@ -535,9 +534,10 @@ A new built-in, \function{zip(\var{seq1}, \var{seq2}, ...)}, has been ...@@ -535,9 +534,10 @@ A new built-in, \function{zip(\var{seq1}, \var{seq2}, ...)}, has been
added. \function{zip()} returns a list of tuples where each tuple added. \function{zip()} returns a list of tuples where each tuple
contains the i-th element from each of the argument sequences. The contains the i-th element from each of the argument sequences. The
difference between \function{zip()} and \code{map(None, \var{seq1}, difference between \function{zip()} and \code{map(None, \var{seq1},
\var{seq2})} is that \function{map()} raises an error if the sequences \var{seq2})} is that \function{map()} pads the sequences with
aren't all of the same length, while \function{zip()} truncates the \code{None} if the sequences aren't all of the same length, while
returned list to the length of the shortest argument sequence. \function{zip()} truncates the returned list to the length of the
shortest argument sequence.
The \function{int()} and \function{long()} functions now accept an The \function{int()} and \function{long()} functions now accept an
optional ``base'' parameter when the first argument is a string. optional ``base'' parameter when the first argument is a string.
...@@ -551,7 +551,7 @@ added to the \module{sys} module. \code{sys.version_info} is a tuple ...@@ -551,7 +551,7 @@ added to the \module{sys} module. \code{sys.version_info} is a tuple
\var{serial})} For example, in a hypothetical 2.0.1beta1, \var{serial})} For example, in a hypothetical 2.0.1beta1,
\code{sys.version_info} would be \code{(2, 0, 1, 'beta', 1)}. \code{sys.version_info} would be \code{(2, 0, 1, 'beta', 1)}.
\var{level} is a string such as \code{"alpha"}, \code{"beta"}, or \var{level} is a string such as \code{"alpha"}, \code{"beta"}, or
\code{""} for a final release. \code{"final"} for a final release.
Dictionaries have an odd new method, \method{setdefault(\var{key}, Dictionaries have an odd new method, \method{setdefault(\var{key},
\var{default})}, which behaves similarly to the existing \var{default})}, which behaves similarly to the existing
...@@ -609,7 +609,7 @@ similarly easy-going. 2.0alpha1 tightened these functions up, but ...@@ -609,7 +609,7 @@ similarly easy-going. 2.0alpha1 tightened these functions up, but
because the documentation actually used the erroneous multiple because the documentation actually used the erroneous multiple
argument form, many people wrote code which would break with the argument form, many people wrote code which would break with the
stricter checking. GvR backed out the changes in the face of public stricter checking. GvR backed out the changes in the face of public
reaction, so for the\module{socket} module, the documentation was reaction, so for the \module{socket} module, the documentation was
fixed and the multiple argument form is simply marked as deprecated; fixed and the multiple argument form is simply marked as deprecated;
it \emph{will} be tightened up again in a future Python version. it \emph{will} be tightened up again in a future Python version.
...@@ -631,16 +631,15 @@ of a long integer no longer has a trailing 'L' character, though ...@@ -631,16 +631,15 @@ of a long integer no longer has a trailing 'L' character, though
\function{repr()} still includes it. The 'L' annoyed many people who \function{repr()} still includes it. The 'L' annoyed many people who
wanted to print long integers that looked just like regular integers, wanted to print long integers that looked just like regular integers,
since they had to go out of their way to chop off the character. This since they had to go out of their way to chop off the character. This
is no longer a problem in 2.0, but code which assumes the 'L' is is no longer a problem in 2.0, but code which does \code{str(longval)[:-1]} and assumes the 'L' is there, will now lose
there, and does \code{str(longval)[:-1]} will now lose the final the final digit.
digit.
Taking the \function{repr()} of a float now uses a different Taking the \function{repr()} of a float now uses a different
formatting precision than \function{str()}. \function{repr()} uses formatting precision than \function{str()}. \function{repr()} uses
\code{\%.17g} format string for C's \function{sprintf()}, while \code{\%.17g} format string for C's \function{sprintf()}, while
\function{str()} uses \code{\%.12g} as before. The effect is that \function{str()} uses \code{\%.12g} as before. The effect is that
\function{repr()} may occasionally show more decimal places than \function{repr()} may occasionally show more decimal places than
\function{str()}, for numbers \function{str()}, for certain numbers.
For example, the number 8.1 can't be represented exactly in binary, so For example, the number 8.1 can't be represented exactly in binary, so
\code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is \code{repr(8.1)} is \code{'8.0999999999999996'}, while str(8.1) is
\code{'8.1'}. \code{'8.1'}.
...@@ -727,7 +726,7 @@ only supports K\&R C. ...@@ -727,7 +726,7 @@ only supports K\&R C.
Before Python 2.0, installing modules was a tedious affair -- there Before Python 2.0, installing modules was a tedious affair -- there
was no way to figure out automatically where Python is installed, or was no way to figure out automatically where Python is installed, or
what compiler options to use for extension modules. Software authors what compiler options to use for extension modules. Software authors
had to go through an ardous ritual of editing Makefiles and had to go through an arduous ritual of editing Makefiles and
configuration files, which only really work on Unix and leave Windows configuration files, which only really work on Unix and leave Windows
and MacOS unsupported. Software users faced wildly differing and MacOS unsupported. Software users faced wildly differing
installation instructions installation instructions
...@@ -835,8 +834,8 @@ interfaces. ...@@ -835,8 +834,8 @@ interfaces.
The \module{Tkinter} module now supports Tcl/Tk version 8.1, 8.2, or The \module{Tkinter} module now supports Tcl/Tk version 8.1, 8.2, or
8.3, and support for the older 7.x versions has been dropped. The 8.3, and support for the older 7.x versions has been dropped. The
Tkinter module now supports displaying Unicode strings in Tk widgets. Tkinter module now supports displaying Unicode strings in Tk widgets.
Also, Fredrik Lundh contributed an optimization which make operations Also, Fredrik Lundh contributed an optimization which makes operations
like \code{create_line} and \code{create_polygon} are much faster, like \code{create_line} and \code{create_polygon} much faster,
especially when using lots of coordinates. especially when using lots of coordinates.
The \module{curses} module has been greatly extended, starting from The \module{curses} module has been greatly extended, starting from
...@@ -895,12 +894,12 @@ A.M. Kuchling.) ...@@ -895,12 +894,12 @@ A.M. Kuchling.)
\item{\module{robotparser}:} Parse a \file{robots.txt} file, which is \item{\module{robotparser}:} Parse a \file{robots.txt} file, which is
used for writing Web spiders that politely avoid certain areas of a used for writing Web spiders that politely avoid certain areas of a
Web site. The parser accepts the contents of a \file{robots.txt} file Web site. The parser accepts the contents of a \file{robots.txt} file,
builds a set of rules from it, and can then answer questions about builds a set of rules from it, and can then answer questions about
the fetchability of a given URL. (Contributed by Skip Montanaro.) the fetchability of a given URL. (Contributed by Skip Montanaro.)
\item{\module{tabnanny}:} A module/script to \item{\module{tabnanny}:} A module/script to
checks Python source code for ambiguous indentation. check Python source code for ambiguous indentation.
(Contributed by Tim Peters.) (Contributed by Tim Peters.)
\item{\module{UserString}:} A base class useful for deriving objects that behave like strings. \item{\module{UserString}:} A base class useful for deriving objects that behave like strings.
...@@ -992,7 +991,8 @@ these modules. ...@@ -992,7 +991,8 @@ these modules.
\section{Acknowledgements} \section{Acknowledgements}
The authors would like to thank the following people for offering The authors would like to thank the following people for offering
suggestions on drafts of this article: Fredrik Lundh, Skip suggestions on drafts of this article: Mark Hammond, Fredrik Lundh,
Montanaro, Vladimir Marangozov, Guido van Rossum, Neil Schemenauer. Detlef Lannert, Skip Montanaro, Vladimir Marangozov, Guido van Rossum,
and Neil Schemenauer.
\end{document} \end{document}
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment