summaryrefslogtreecommitdiffstats
path: root/Doc/whatsnew/whatsnew20.tex
diff options
context:
space:
mode:
authorAndrew M. Kuchling <amk@amk.ca>2000-09-06 17:58:49 (GMT)
committerAndrew M. Kuchling <amk@amk.ca>2000-09-06 17:58:49 (GMT)
commit4d46d38292525b3a018ea84418432fedd5418b8c (patch)
tree72b5393f2018b700b59bbd8d1426041c40e09360 /Doc/whatsnew/whatsnew20.tex
parent4338a284b80ae8dd8cc45c27a0e66c525ba5d63c (diff)
downloadcpython-4d46d38292525b3a018ea84418432fedd5418b8c.zip
cpython-4d46d38292525b3a018ea84418432fedd5418b8c.tar.gz
cpython-4d46d38292525b3a018ea84418432fedd5418b8c.tar.bz2
Add new section "What About Python 1.6?"
Document some things in the 2.0 NEWS files that should be mentioned here.
Diffstat (limited to 'Doc/whatsnew/whatsnew20.tex')
-rw-r--r--Doc/whatsnew/whatsnew20.tex57
1 files changed, 55 insertions, 2 deletions
diff --git a/Doc/whatsnew/whatsnew20.tex b/Doc/whatsnew/whatsnew20.tex
index 2341d34..341b706 100644
--- a/Doc/whatsnew/whatsnew20.tex
+++ b/Doc/whatsnew/whatsnew20.tex
@@ -30,6 +30,29 @@ impossible, but they're certainly significant. Consult the
publicly-available CVS logs if you want to see the full list.
% ======================================================================
+\section{What About Python 1.6?}
+
+Python 1.6 can be thought of as the Contractual Obligations Python
+release. After the core development team left CNRI in May 2000, CNRI
+requested that a 1.6 release be created, containing all the work on
+Python that had been performed at CNRI. Python 1.6 therefore
+represents the state of the CVS tree as of May 2000, with the most
+significant new feature being Unicode support. Development continued
+after May, of course, so the 1.6 tree received a few fixes to ensure
+that it's forward-compatible with Python 2.0. 1.6 is therefore part
+of Python's evolution, and not a side branch.
+
+So, should you take much interest in Python 1.6? Probably not. The
+1.6final and 2.0beta1 releases were made on the same day (September 5,
+2000), the plan being to finalize Python 2.0 within a month or so. If
+you have applications to maintain, there seems little point in
+breaking things by moving to 1.6, fixing them, and then having another
+round of breakage within a month by moving to 2.0; you're better off
+just going straight to 2.0. Most of the really interesting features
+described in this document are only in 2.0, because a lot of work was
+done between May and September.
+
+% ======================================================================
\section{Unicode}
The largest new feature in Python 2.0 is a new fundamental data type:
@@ -528,6 +551,11 @@ def f():
f()
\end{verbatim}
+Two new exceptions, \exception{TabError} and
+\exception{IndentationError}, have been introduced. They're both
+subclasses of \exception{SyntaxError}, and are raised when Python code
+is found to be improperly indented.
+
\subsection{Changes to Built-in Functions}
A new built-in, \function{zip(\var{seq1}, \var{seq2}, ...)}, has been
@@ -569,14 +597,22 @@ else:
can be reduced to a single \code{return dict.setdefault(key, [])} statement.
+The interpreter sets a maximum recursion depth in order to catch
+runaway recursion before filling the C stack and causing a core dump
+or GPF.. Previously this limit was fixed when you compiled Python,
+but in 2.0 the maximum recursion depth can be read and modified using
+\function{sys.getrecursionlimit} and \function{sys.setrecursionlimit}.
+The default value is 1000, and a rough maximum value for a given
+platform can be found by running a new script,
+\file{Misc/find_recursionlimit.py}.
% ======================================================================
\section{Porting to 2.0}
New Python releases try hard to be compatible with previous releases,
and the record has been pretty good. However, some changes are
-considered useful enough, often fixing initial design decisions that
-turned to be actively mistaken, that breaking backward compatibility
+considered useful enough, usually because they fix initial design decisions that
+turned out to be actively mistaken, that breaking backward compatibility
can't always be avoided. This section lists the changes in Python 2.0
that may cause old Python code to break.
@@ -613,6 +649,16 @@ reaction, so for the \module{socket} module, the documentation was
fixed and the multiple argument form is simply marked as deprecated;
it \emph{will} be tightened up again in a future Python version.
+The \code{\e x} escape in string literals now takes exactly 2 hex
+digits. Previously it would consume all the hex digits following the
+'x' and take the lowest 8 bits of the result, so \code{\e x123456} was
+equivalent to \code{\e x56}.
+
+The \exception{AttributeError} exception has a more friendly error message,
+whose text will be something like \code{'Spam' instance has no attribute 'eggs'}.
+Previously the error message was just the missing attribute name \code{eggs}, and
+code written to take advantage of this fact will break in 2.0.
+
Some work has been done to make integers and long integers a bit more
interchangeable. In 1.5.2, large-file support was added for Solaris,
to allow reading files larger than 2Gb; this made the \method{tell()}
@@ -720,6 +766,13 @@ Python 2.0's source now uses only ANSI C prototypes, so compiling Python now
requires an ANSI C compiler, and can no longer be done using a compiler that
only supports K\&R C.
+Previously the Python virtual machine used 16-bit numbers in its
+bytecode, limiting the size of source files. In particular, this
+affected the maximum size of literal lists and dictionaries in Python
+source; occasionally people who are generating Python code would run into this limit.
+A patch by Charles G. Waldman raises the limit from \verb|2^16| to \verb|2^{32}|.
+
+
% ======================================================================
\section{Distutils: Making Modules Easy to Install}