[Python-checkins] r43707 - python/trunk/Doc/whatsnew/whatsnew25.tex
andrew.kuchling
python-checkins at python.org
Thu Apr 6 15:03:06 CEST 2006
Author: andrew.kuchling
Date: Thu Apr 6 15:03:04 2006
New Revision: 43707
Modified:
python/trunk/Doc/whatsnew/whatsnew25.tex
Log:
Expand the PEP 353 section; various smaller changes
Modified: python/trunk/Doc/whatsnew/whatsnew25.tex
==============================================================================
--- python/trunk/Doc/whatsnew/whatsnew25.tex (original)
+++ python/trunk/Doc/whatsnew/whatsnew25.tex Thu Apr 6 15:03:04 2006
@@ -249,10 +249,8 @@
way to ignore \module{pkg.string} and look for the standard module;
generally you had to look at the contents of \code{sys.modules}, which
is slightly unclean.
-Holger Krekel's py.std package provides a tidier way to perform
-imports from the standard library, \code{from py.std import string},
-% XXX correct attribution?
-% XXX is that import correct?
+Holger Krekel's \module{py.std} package provides a tidier way to perform
+imports from the standard library, \code{import py ; py.std.string.join()},
but that package isn't available on all Python installations.
Reading code which relies on relative imports is also less clear,
@@ -266,7 +264,7 @@
In Python 2.5, you can switch \keyword{import}'s behaviour to
absolute imports using a \code{from __future__ import absolute_import}
directive. This absolute-import behaviour will become the default in
-a future version (probably Python 2.6). Once absolute-imports
+a future version (probably Python 2.7). Once absolute imports
are the default, \code{import string} will
always find the standard library's version.
It's suggested that users should begin using absolute imports as much
@@ -300,10 +298,11 @@
\begin{seealso}
-\seepep{328}{Imports: Multi-Line and Absolute/Relative}{PEP written
-by Aahz; implemented by XXX.}
+\seepep{328}{Imports: Multi-Line and Absolute/Relative}
+{PEP written by Aahz; implemented by Thomas Wouters.}
-%\seeurl{http://codespeak.net/py/current/doc/misc.html\#mapping-the-standard-python-library-into-py}{py.std}
+\seeurl{http://codespeak.net/py/current/doc/index.html}
+{The py library by Holger Krekel, which contains the \module{py.std} package.}
\end{seealso}
@@ -701,21 +700,67 @@
%======================================================================
-\section{PEP 353: Using ssize_t as the index type}
+\section{PEP 353: Using ssize_t as the index type\label{section-353}}
A wide-ranging change to Python's C API, using a new
\ctype{Py_ssize_t} type definition instead of \ctype{int},
will permit the interpreter to handle more data on 64-bit platforms.
This change doesn't affect Python's capacity on 32-bit platforms.
-This section will be expanded in future alpha releases.
+Various pieces of the Python interpreter used C's \ctype{int} type to
+store sizes or counts; for example, the number of items in a list or
+tuple were stored in an \ctype{int}. The C compilers for most 64-bit
+platforms still define \ctype{int} as a 32-bit type, so that meant
+that lists could only hold up to \code{2**31 - 1} = 2147483647 items.
+(There are actually a few different programming models that 64-bit C
+compilers can use -- see
+\url{http://www.unix.org/version2/whatsnew/lp64_wp.html} for a
+discussion -- but the most commonly available model leaves \ctype{int}
+as 32 bits.)
+
+A limit of 2147483647 items doesn't really matter on a 32-bit platform
+because you'll run out of memory before hitting the length limit.
+Each list item requires space for a pointer, which is 4 bytes, plus
+space for a \ctype{PyObject} representing the item. 2147483647*4 is
+already more bytes than a 32-bit address space can contain.
+
+It's possible to address that much memory on a 64-bit platform,
+however. The pointers for a list that size would only require 16GiB
+of space, so it's not unreasonable that Python programmers might
+construct lists that large. Therefore, the Python interpreter had to
+be changed to use some type other than \ctype{int}, and this will be a
+64-bit type on 64-bit platforms. The change will cause
+incompatibilities on 64-bit machines, so it was deemed worth making
+the transition now, while the number of 64-bit users is still
+relatively small. (In 5 or 10 years, we may \emph{all} be on 64-bit
+machines, and the transition would be more painful then.)
+
+This change most strongly affects authors of C extension modules.
+Python strings and container types such as lists and tuples
+now use \ctype{Py_ssize_t} to store their size.
+Functions such as \cfunction{PyList_Size()}
+now return \ctype{Py_ssize_t}. Code in extension modules
+may therefore need to have some variables changed to
+\ctype{Py_ssize_t}.
+
+The \cfunction{PyArg_ParseTuple()} and \cfunction{Py_BuildValue()} functions
+have a new conversion code, \samp{n}, for \ctype{Py_ssize_t}.
+\cfunction{PyArg_ParseTuple()}'s \samp{s#} and \samp{t#} still output
+\ctype{int} by default, but you can define the macro
+\csimplemacro{PY_SSIZE_T_CLEAN} before including \file{Python.h}
+to make them return \ctype{Py_ssize_t}.
+
+\pep{353} has a section on conversion guidelines that
+extension authors should read to learn about supporting 64-bit
+platforms.
\begin{seealso}
-\seepep{353}{}{PEP written and implemented by Martin von L\"owis.}
+\seepep{353}{Using ssize_t as the index type}{PEP written and implemented by Martin von L\"owis.}
\end{seealso}
+
%======================================================================
\section{PEP 357: The '__index__' method}
@@ -1044,7 +1089,8 @@
been added to the standard library as \module{xml.etree}. The
vailable modules are
\module{ElementTree}, \module{ElementPath}, and
-\module{ElementInclude} from ElementTree 1.2.6.
+\module{ElementInclude} from ElementTree 1.2.6.
+The \module{cElementTree} accelerator module is also included.
In subsequent alpha releases of Python 2.5, I'll add a brief
introduction that will provide a page-long overview of using
@@ -1134,7 +1180,11 @@
\begin{itemize}
-% XXX PEP 353: ssize_t
+\item The largest change to the C API came from \pep{353},
+which modifies the interpreter to use a \ctype{Py_ssize_t} type
+definition instead of \ctype{int}. See the earlier
+section~ref{section-353} for a discussion of this change.
+
\item The design of the bytecode compiler has changed a great deal, to
no longer generate bytecode by traversing the parse tree. Instead
the parse tree is converted to an abstract syntax tree (or AST), and it is
@@ -1227,6 +1277,6 @@
The author would like to thank the following people for offering
suggestions, corrections and assistance with various drafts of this
-article: no one yet.
+article: Thomas Wouters.
\end{document}
More information about the Python-checkins
mailing list