Add new section "What About Python 1.6?"
Document some things in the 2.0 NEWS files that should be mentioned here.
This commit is contained in:
parent
4338a284b8
commit
4d46d38292
|
@ -29,6 +29,29 @@ better error messages went into 2.0; to list them all would be
|
|||
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}
|
||||
|
||||
|
@ -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}
|
||||
|
||||
|
|
Loading…
Reference in New Issue