[Python-checkins] python/dist/src/Doc/whatsnew whatsnew23.tex,1.11,1.12
akuchling@sourceforge.net
akuchling@sourceforge.net
Tue, 07 May 2002 14:01:19 -0700
Update of /cvsroot/python/python/dist/src/Doc/whatsnew
In directory usw-pr-cvs1:/tmp/cvs-serv23617
Modified Files:
whatsnew23.tex
Log Message:
More filling out
Index: whatsnew23.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/whatsnew/whatsnew23.tex,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** whatsnew23.tex 6 May 2002 17:46:39 -0000 1.11
--- whatsnew23.tex 7 May 2002 21:01:16 -0000 1.12
***************
*** 2,5 ****
--- 2,8 ----
% $Id$
+ % TODO:
+ % Go through and get the contributor's name for all the various changes
+
\title{What's New in Python 2.3}
\release{0.01}
***************
*** 33,38 ****
%======================================================================
! \section{PEP 255: Simple Generators}
! \label{section-generators}
In Python 2.2, generators were added as an optional feature, to be
--- 36,40 ----
%======================================================================
! \section{PEP 255: Simple Generators\label{section-generators}}
In Python 2.2, generators were added as an optional feature, to be
***************
*** 44,56 ****
it when 2.2 came out, you can skip the rest of this section.
! Generators are a new feature that interacts with the iterators
! introduced in Python 2.2.
!
! You're doubtless familiar with how function calls work in Python or
! C. When you call a function, it gets a private namespace where its local
variables are created. When the function reaches a \keyword{return}
statement, the local variables are destroyed and the resulting value
is returned to the caller. A later call to the same function will get
! a fresh new set of local variables. But, what if the local variables
weren't thrown away on exiting a function? What if you could later
resume the function where it left off? This is what generators
--- 46,55 ----
it when 2.2 came out, you can skip the rest of this section.
! You're doubtless familiar with how function calls work in Python or C.
! When you call a function, it gets a private namespace where its local
variables are created. When the function reaches a \keyword{return}
statement, the local variables are destroyed and the resulting value
is returned to the caller. A later call to the same function will get
! a fresh new set of local variables. But, what if the local variables
weren't thrown away on exiting a function? What if you could later
resume the function where it left off? This is what generators
***************
*** 186,195 ****
The three major operating systems used today are Microsoft Windows,
! Apple's Macintosh OS, and the various Unix derivatives. A minor
irritation is that these three platforms all use different characters
! to mark the ends of lines in text files. Unix uses character 10, the
! ASCII linefeed, MacOS uses character 13, the ASCII carriage return,
! and Windows uses a two-character sequence of carriage return plus a
! newline.
Python's file objects can now support end of line conventions other
--- 185,194 ----
The three major operating systems used today are Microsoft Windows,
! Apple's Macintosh OS, and the various \UNIX\ derivatives. A minor
irritation is that these three platforms all use different characters
! to mark the ends of lines in text files. \UNIX\ uses character 10,
! the ASCII linefeed, while MacOS uses character 13, the ASCII carriage
! return, and Windows uses a two-character sequence of a carriage return
! plus a newline.
Python's file objects can now support end of line conventions other
***************
*** 206,212 ****
without needing to convert the line-endings.
! This feature can be disabled at compile-time by specifying the
\longprogramopt{without-universal-newlines} when running Python's
! configure script.
\begin{seealso}
--- 205,211 ----
without needing to convert the line-endings.
! This feature can be disabled at compile-time by specifying
\longprogramopt{without-universal-newlines} when running Python's
! \file{configure} script.
\begin{seealso}
***************
*** 218,223 ****
%======================================================================
! \section{PEP 285: The \class{bool} Type}
! \label{section-bool}
A Boolean type was added to Python 2.3. Two new constants were added
--- 217,222 ----
%======================================================================
! \section{PEP 285: The \class{bool} Type\label{section-bool}}
!
A Boolean type was added to Python 2.3. Two new constants were added
***************
*** 242,251 ****
\begin{verbatim}
! >>> o = []
! >>> hasattr(o, 'append')
True
! >>> isinstance(o, list)
True
! >>> isinstance(o, tuple)
False
\end{verbatim}
--- 241,250 ----
\begin{verbatim}
! >>> obj = []
! >>> hasattr(obj, 'append')
True
! >>> isinstance(obj, list)
True
! >>> isinstance(obj, tuple)
False
\end{verbatim}
***************
*** 294,297 ****
--- 293,399 ----
%======================================================================
+ \section{Other Language Changes}
+
+ Here are the changes that Python 2.3 makes to the core language.
+
+ \begin{itemize}
+ \item The \keyword{yield} statement is now always a keyword, as
+ described in section~\ref{section-generators}.
+
+ \item Two new constants, \constant{True} and \constant{False} were
+ added along with the built-in \class{bool} type, as described in
+ section~\ref{section-bool}.
+
+ \item A new built-in function, \function{enumerate()}, will make
+ certain loops a bit clearer. \code{enumerate(thing)}, where
+ \var{thing} is either an iterator or a sequence, returns a iterator
+ that will return \code{(0, \var{thing[0]})}, \code{(1,
+ \var{thing[1]})}, \code{(2, \var{thing[2]})}, and so forth. Fairly
+ often you'll see code to change every element of a list that looks like this:
+
+ \begin{verbatim}
+ for i in range(len(L)):
+ item = L[i]
+ # ... compute some result based on item ...
+ L[i] = result
+ \end{verbatim}
+
+ This can be rewritten using \function{enumerate()} as:
+
+ \begin{verbatim}
+ for i, item in enumerate(L):
+ # ... compute some result based on item ...
+ L[i] = result
+ \end{verbatim}
+
+ \end{itemize}
+
+
+ %======================================================================
+ \section{Specialized Object Allocator (pymalloc)\label{section-pymalloc}}
+
+ An experimental feature added to Python 2.1 was a specialized object
+ allocator called pymalloc, written by Vladimir Marangozov. Pymalloc
+ was intended to be faster than the system \function{malloc()} and have
+ less memory overhead. The allocator uses C's \function{malloc()}
+ function to get large pools of memory, and then fulfills smaller
+ memory requests from these pools.
+
+ In 2.1 and 2.2, pymalloc was an experimental feature and wasn't
+ enabled by default; you had to explicitly turn it on by providing the
+ \longprogramopt{with-pymalloc} option to the \program{configure}
+ script. In 2.3, pymalloc has had further enhancements and is now
+ enabled by default; you'll have to supply
+ \longprogramopt{without-pymalloc} to disable it.
+
+ This change is transparent to code written in Python; however,
+ pymalloc may expose bugs in C extensions. Authors of C extension
+ modules should test their code with the object allocator enabled,
+ because some incorrect code may cause core dumps at runtime. There
+ are a bunch of memory allocation functions in Python's C API that have
+ previously been just aliases for the C library's \function{malloc()}
+ and \function{free()}, meaning that if you accidentally called
+ mismatched functions, the error wouldn't be noticeable. When the
+ object allocator is enabled, these functions aren't aliases of
+ \function{malloc()} and \function{free()} any more, and calling the
+ wrong function to free memory will get you a core dump. For example,
+ if memory was allocated using \function{PyMem_New()}, it has to be
+ freed using \function{PyMem_Del()}, not \function{free()}. A few
+ modules included with Python fell afoul of this and had to be fixed;
+ doubtless there are more third-party modules that will have the same
+ problem.
+
+ As part of this change, the confusing multiple interfaces for
+ allocating memory have been consolidated down into two APIs.
+ Memory allocated with one API must not be freed with the other API.
+
+ \begin{itemize}
+ \item To allocate and free an undistinguished chunk of memory, use
+ \cfunction{PyMem_Malloc()}, \cfunction{PyMem_Realloc()},
+ \cfunction{PyMem_Free()}, and the other \cfunction{PyMem_*}
+ functions.
+
+ \item To allocate and free Python objects,
+ use \cfunction{PyObject_New()}, \cfunction{PyObject_NewVar()}, and
+ \cfunction{PyObject_Del()}.
+ \end{itemize}
+
+ Thanks to lots of work by Tim Peters, pymalloc in 2.3 also provides
+ debugging features to catch memory overwrites and doubled frees in
+ both extension modules and in the interpreter itself. To enable this
+ support, turn on the Python interpreter's debugging code by running
+ \program{configure} with \longprogramopt{with-pydebug}.
+
+ \begin{seealso}
+
+ \seeurl{XXX}
+ {For the full details of the pymalloc implementation, see
+ the comments at the top of the file \file{Objects/obmalloc.c} in the
+ Python source code. The above link points to the file within the
+ SourceForge CVS browser.}
+
+ \end{seealso}
+
+ %======================================================================
\section{New and Improved Modules}
***************
*** 348,352 ****
>>> '12345'.zfill(4)
'12345'
! >>> 'goofy'.zfill(4)
'0goofy'
\end{verbatim}
--- 450,454 ----
>>> '12345'.zfill(4)
'12345'
! >>> 'goofy'.zfill(6)
'0goofy'
\end{verbatim}
***************
*** 377,390 ****
\end{verbatim}
- distutils: command/bdist_packager, support for Solaris pkgtool
- and HP-UX swinstall
-
-
\item Two new functions, \function{killpg()} and \function{mknod()},
were added to the \module{posix} module that underlies the \module{os}
module.
! \item (XXX write this) arraymodule.c: - add Py_UNICODE arrays
! - support +=, *=
\item The \module{grp} module now returns enhanced tuples:
--- 479,496 ----
\end{verbatim}
\item Two new functions, \function{killpg()} and \function{mknod()},
were added to the \module{posix} module that underlies the \module{os}
module.
! \item Two new binary packagers were added to the Distutils.
! \code{bdist_pkgtool} builds \file{.pkg} files to use with Solaris
! \program{pkgtool}, and \code{bdist_sdux} builds \program{swinstall}
! packages for use on HP-UX. (Contributed by Mark Alexander.)
!
! \item The \module{array} module now supports arrays of Unicode
! characters using the \samp{u} format character. Arrays also
! now support using the \code{+=} assignment operator to add another array's
! contents, and the \code{*=} assignment operator to repeat an array.
! (Contributed by XXX.)
\item The \module{grp} module now returns enhanced tuples:
***************
*** 404,460 ****
- New enumerate() built-in.
-
- %======================================================================
- \section{Interpreter Changes and Fixes}
-
- Here are the changes that Python 2.3 makes to the core language.
-
- \begin{itemize}
- \item The \keyword{yield} statement is now always a keyword, as
- described in section~\ref{section-generators}.
-
- \item Two new constants, \constant{True} and \constant{False} were
- added along with the built-in \class{bool} type, as described in
- section~\ref{section-bool}.
-
- \item The \class{file} type can now be subtyped. (XXX did this not work
- before? Thought I used it in an example in the 2.2 What's New document...)
-
- \item File objects also manage their internal string buffer
- differently by increasing it exponentially when needed.
- This results in the benchmark tests in \file{Lib/test/test_bufio.py}
- speeding up from 57 seconds to 1.7 seconds, according to one
- measurement.
-
- \end{itemize}
-
-
- %======================================================================
- \section{Other Changes and Fixes}
-
- XXX write this
-
- The tools used to build the documentation now work under Cygwin as
- well as \UNIX.
-
-
% ======================================================================
\section{Build and C API Changes}
! XXX write this
\begin{itemize}
! \item Patch \#527027: Allow building python as shared library with
! --enable-shared
!
! pymalloc is now enabled by default (also mention debug-mode pymalloc)
!
! Memory API reworking -- which functions are deprecated?
! PyObject_DelItemString() added
! PyArg_NoArgs macro is now deprecated
\item The source code for the Expat XML parser is now included with
--- 510,534 ----
% ======================================================================
\section{Build and C API Changes}
! Changes to Python's build process, and to the C API, include:
\begin{itemize}
! \item Python can now optionally be built as a shared library
! (\file{libpython2.3.so}) by supplying \longprogramopt{enable-shared}
! when running Python's \file{configure} script. (Contributed by XXX
! Patch \#527027)
! \item The \cfunction{PyArg_NoArgs()} macro is now deprecated, and code
! that
! uses it should be changed to use \code{PyArg_ParseTuple(args, "")}
! instead.
! \item A new function, \cfunction{PyObject_DelItemString(\var{mapping},
! char *\var{key})} was added
! as shorthand for
! \code{PyObject_DelItem(\var{mapping}, PyString_New(\var{key})}.
\item The source code for the Expat XML parser is now included with
***************
*** 462,467 ****
dependent on having a system library containing Expat.
! ===
! Introduce two new flag bits that can be set in a PyMethodDef method
descriptor, as used for the tp_methods slot of a type. These new flag
bits are both optional, and mutually exclusive. Most methods will not
--- 536,546 ----
dependent on having a system library containing Expat.
! \item File objects now manage their internal string buffer
! differently by increasing it exponentially when needed.
! This results in the benchmark tests in \file{Lib/test/test_bufio.py}
! speeding up from 57 seconds to 1.7 seconds, according to one
! measurement.
!
! \item XXX Introduce two new flag bits that can be set in a PyMethodDef method
descriptor, as used for the tp_methods slot of a type. These new flag
bits are both optional, and mutually exclusive. Most methods will not
***************
*** 480,484 ****
these special method types are not meaningful in that case; a
ValueError will be raised if these flags are found in that context.
- ===
\end{itemize}
--- 559,562 ----
***************
*** 488,494 ****
XXX write this
! OS/2 EMX port
! MacOS: Weaklink most toolbox modules, improving backward
compatibility. Modules will no longer fail to load if a single routine
is missing on the curent OS version, in stead calling the missing
--- 566,572 ----
XXX write this
! XXX OS/2 EMX port
! XXX MacOS: Weaklink most toolbox modules, improving backward
compatibility. Modules will no longer fail to load if a single routine
is missing on the curent OS version, in stead calling the missing
***************
*** 497,509 ****
were not Python-compatible.
! Checked in Sean Reifschneider's RPM spec file and patches.
%======================================================================
\section{Acknowledgements \label{acks}}
The author would like to thank the following people for offering
suggestions, corrections and assistance with various drafts of this
! article: Fred~L. Drake, Jr.
\end{document}
--- 575,599 ----
were not Python-compatible.
! XXX Checked in Sean Reifschneider's RPM spec file and patches.
%======================================================================
+ \section{Other Changes and Fixes}
+
+ Finally, there are various miscellaneous fixes:
+
+ \begin{itemize}
+
+ \item The tools used to build the documentation now work under Cygwin
+ as well as \UNIX.
+
+ \end{itemize}
+
+ %======================================================================
\section{Acknowledgements \label{acks}}
The author would like to thank the following people for offering
suggestions, corrections and assistance with various drafts of this
! article: Fred~L. Drake, Jr., Detlef Lannert.
\end{document}