[Python-checkins]
python/dist/src/Doc/whatsnew whatsnew24.tex, 1.60, 1.61
akuchling at users.sourceforge.net
akuchling at users.sourceforge.net
Sun Jul 4 21:37:18 EDT 2004
Update of /cvsroot/python/python/dist/src/Doc/whatsnew
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv8107
Modified Files:
whatsnew24.tex
Log Message:
Various edits
Index: whatsnew24.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/whatsnew/whatsnew24.tex,v
retrieving revision 1.60
retrieving revision 1.61
diff -C2 -d -r1.60 -r1.61
*** whatsnew24.tex 4 Jul 2004 16:39:40 -0000 1.60
--- whatsnew24.tex 5 Jul 2004 01:37:07 -0000 1.61
***************
*** 22,33 ****
\tableofcontents
! This article explains the new features in Python 2.4 alpha1, to be released in early July 2004 The final version of Python 2.4
! is expected to be around September 2004.
! Python 2.4 is a middle-sized release. It doesn't introduce as many
changes as the radical Python 2.2, but introduces more features than
the conservative 2.3 release did. The most significant new language
feature (as of this writing) is the addition of generator expressions;
! most of the changes are to the standard library.
This article doesn't attempt to provide a complete specification of
--- 22,34 ----
\tableofcontents
! This article explains the new features in Python 2.4 alpha1, scheduled
! for release in early July 2004. The final version of Python 2.4 is
! expected to be released around September 2004.
! Python 2.4 is a medium-sized release. It doesn't introduce as many
changes as the radical Python 2.2, but introduces more features than
the conservative 2.3 release did. The most significant new language
feature (as of this writing) is the addition of generator expressions;
! most other changes are to the standard library.
This article doesn't attempt to provide a complete specification of
***************
*** 44,52 ****
\section{PEP 218: Built-In Set Objects}
! Two new built-in types, \function{set(\var{iterable})} and
! \function{frozenset(\var{iterable})} provide high speed data types for
! membership testing, for eliminating duplicates from sequences, and
! for mathematical operations like unions, intersections, differences,
! and symmetric differences.
\begin{verbatim}
--- 45,55 ----
\section{PEP 218: Built-In Set Objects}
! Python 2.3 introduced the \module{sets} module. C implementations of
! set data types have now been added to the Python core as two new
! built-in types, \function{set(\var{iterable})} and
! \function{frozenset(\var{iterable})}. They provide high speed
! operations for membership testing, for eliminating duplicates from
! sequences, and for mathematical operations like unions, intersections,
! differences, and symmetric differences.
\begin{verbatim}
***************
*** 78,91 ****
\end{verbatim}
! The type \function{frozenset()} is an immutable version of \function{set()}.
Since it is immutable and hashable, it may be used as a dictionary key or
! as a member of another set. Accordingly, it does not have methods
! like \method{add()} and \method{remove()} which could alter its contents.
! % XXX what happens to the sets module?
! % The current thinking is that the sets module will be left alone.
! % That way, existing code will continue to run without alteration.
! % Also, the module provides an autoconversion feature not supported by set()
! % and frozenset().
\begin{seealso}
--- 81,91 ----
\end{verbatim}
! The \function{frozenset} type is an immutable version of \function{set}.
Since it is immutable and hashable, it may be used as a dictionary key or
! as a member of another set.
! The \module{sets} module remains in the standard library, and may be
! useful if you wish to subclass the \class{Set} or \class{ImmutableSet}
! classes. There are currently no plans to deprecate the module.
\begin{seealso}
***************
*** 97,117 ****
\section{PEP 237: Unifying Long Integers and Integers}
! The lengthy transition process for the PEP, begun with Python 2.2,
takes another step forward in Python 2.4. In 2.3, certain integer
operations that would behave differently after int/long unification
triggered \exception{FutureWarning} warnings and returned values
! limited to 32 or 64 bits. In 2.4, these expressions no longer produce
! a warning, but they now produce a different value that's a long
! integer.
The problematic expressions are primarily left shifts and lengthy
! hexadecimal and octal constants. For example, \code{2 << 32} is one
! expression that results in a warning in 2.3, evaluating to 0 on 32-bit
! platforms. In Python 2.4, this expression now returns 8589934592.
!
\begin{seealso}
\seepep{237}{Unifying Long Integers and Integers}{Original PEP
! written by Moshe Zadka and Gvr. The changes for 2.4 were implemented by
Kalle Svensson.}
\end{seealso}
--- 97,116 ----
\section{PEP 237: Unifying Long Integers and Integers}
! The lengthy transition process for this PEP, begun in Python 2.2,
takes another step forward in Python 2.4. In 2.3, certain integer
operations that would behave differently after int/long unification
triggered \exception{FutureWarning} warnings and returned values
! limited to 32 or 64 bits (depending on your platform). In 2.4, these
! expressions no longer produce a warning and instead produce a
! different result that's usually a long integer.
The problematic expressions are primarily left shifts and lengthy
! hexadecimal and octal constants. For example, \code{2 << 32} results
! in a warning in 2.3, evaluating to 0 on 32-bit platforms. In Python
! 2.4, this expression now returns the correct answer, 8589934592.
\begin{seealso}
\seepep{237}{Unifying Long Integers and Integers}{Original PEP
! written by Moshe Zadka and GvR. The changes for 2.4 were implemented by
Kalle Svensson.}
\end{seealso}
***************
*** 125,131 ****
\module{itertools} module to write code in a fairly functional style.
! The fly in the ointment has been list comprehensions, because they
produce a Python list object containing all of the items, unavoidably
! pulling them all into memory. When trying to write a program using the functional approach, it would be natural to write something like:
\begin{verbatim}
--- 124,133 ----
\module{itertools} module to write code in a fairly functional style.
! % XXX avoid metaphor
! List comprehensions have been the fly in the ointment because they
produce a Python list object containing all of the items, unavoidably
! pulling them all into memory. When trying to write a
! functionally-styled program, it would be natural to write something
! like:
\begin{verbatim}
***************
*** 167,176 ****
\end{verbatim}
! There are some small differences from list comprehensions. Most
! notably, the loop variable (\var{obj} in the above example) is not
! accessible outside of the generator expression. List comprehensions
! leave the variable assigned to its last value; future versions of
! Python will change this, making list comprehensions match generator
! expressions in this respect.
\begin{seealso}
--- 169,178 ----
\end{verbatim}
! Generator expressions differ from list comprehensions in various small
! ways. Most notably, the loop variable (\var{obj} in the above
! example) is not accessible outside of the generator expression. List
! comprehensions leave the variable assigned to its last value; future
! versions of Python will change this, making list comprehensions match
! generator expressions in this respect.
\begin{seealso}
***************
*** 183,187 ****
A new built-in function, \function{reversed(\var{seq})}, takes a sequence
! and returns an iterator that returns the elements of the sequence
in reverse order.
--- 185,189 ----
A new built-in function, \function{reversed(\var{seq})}, takes a sequence
! and returns an iterator that loops over the elements of the sequence
in reverse order.
***************
*** 195,200 ****
\end{verbatim}
! Compared to extended slicing, \code{range(1,4)[::-1]}, \function{reversed()}
! is easier to read, runs faster, and uses substantially less memory.
Note that \function{reversed()} only accepts sequences, not arbitrary
--- 197,203 ----
\end{verbatim}
! Compared to extended slicing, such as \code{range(1,4)[::-1]},
! \function{reversed()} is easier to read, runs faster, and uses
! substantially less memory.
Note that \function{reversed()} only accepts sequences, not arbitrary
***************
*** 451,455 ****
mapping, any iterable of key/value pairs, and keyword arguments.
! \item The string methods, \method{ljust()}, \method{rjust()}, and
\method{center()} now take an optional argument for specifying a
fill character other than a space.
--- 454,458 ----
mapping, any iterable of key/value pairs, and keyword arguments.
! \item The string methods \method{ljust()}, \method{rjust()}, and
\method{center()} now take an optional argument for specifying a
fill character other than a space.
***************
*** 467,471 ****
\item The \method{sort()} method of lists gained three keyword
! arguments, \var{cmp}, \var{key}, and \var{reverse}. These arguments
make some common usages of \method{sort()} simpler. All are optional.
--- 470,474 ----
\item The \method{sort()} method of lists gained three keyword
! arguments: \var{cmp}, \var{key}, and \var{reverse}. These arguments
make some common usages of \method{sort()} simpler. All are optional.
***************
*** 497,501 ****
using a \var{key} parameter. Using \var{key} results in calling the
\method{lower()} method once for each element in the list while using
! \var{cmp} will call the method twice for each comparison.
For simple key functions and comparison functions, it is often
--- 500,504 ----
using a \var{key} parameter. Using \var{key} results in calling the
\method{lower()} method once for each element in the list while using
! \var{cmp} will call it twice for each comparison.
For simple key functions and comparison functions, it is often
***************
*** 510,517 ****
\end{verbatim}
! The \var{reverse} parameter should have a Boolean value. If the value is
! \constant{True}, the list will be sorted into reverse order. Instead
! of \code{L.sort(lambda x,y: cmp(y.score, x.score))}, you can now write:
! \code{L.sort(key = lambda x: x.score, reverse=True)}.
The results of sorting are now guaranteed to be stable. This means
--- 513,521 ----
\end{verbatim}
! The \var{reverse} parameter should have a Boolean value. If the value
! is \constant{True}, the list will be sorted into reverse order.
! Instead of \code{L.sort(lambda x,y: cmp(x.score, y.score)) ;
! L.reverse()}, you can now write: \code{L.sort(key = lambda x: x.score,
! reverse=True)}.
The results of sorting are now guaranteed to be stable. This means
***************
*** 523,527 ****
\item There is a new built-in function
\function{sorted(\var{iterable})} that works like the in-place
! \method{list.sort()} method but has been made suitable for use in
expressions. The differences are:
\begin{itemize}
--- 527,531 ----
\item There is a new built-in function
\function{sorted(\var{iterable})} that works like the in-place
! \method{list.sort()} method but can be used in
expressions. The differences are:
\begin{itemize}
***************
*** 551,555 ****
red 1
yellow 5
-
\end{verbatim}
--- 555,558 ----
***************
*** 559,564 ****
\item The \function{zip()} built-in function and \function{itertools.izip()}
! now return an empty list instead of raising a \exception{TypeError}
! exception if called with no arguments. This makes them more
suitable for use with variable length argument lists:
--- 562,568 ----
\item The \function{zip()} built-in function and \function{itertools.izip()}
! now return an empty list if called with no arguments.
! Previously they raised a \exception{TypeError}
! exception. This makes them more
suitable for use with variable length argument lists:
***************
*** 581,606 ****
\begin{itemize}
! \item The inner loops for \class{list} and \class{tuple} slicing
were optimized and now run about one-third faster. The inner
! loops were also optimized for \class{dict} with performance
boosts to \method{keys()}, \method{values()}, \method{items()},
\method{iterkeys()}, \method{itervalues()}, and \method{iteritems()}.
! \item The machinery for growing and shrinking lists was optimized
! for speed and for space efficiency. Small lists (under eight elements)
! never over-allocate by more than three elements. Large lists do not
! over-allocate by more than 1/8th. Appending and popping from lists
! now runs faster due to more efficient code paths and less frequent
! use of the underlying system realloc(). List comprehensions also
! benefit. The amount of improvement varies between systems and shows
! the greatest improvement on systems with poor realloc() implementations.
! \method{list.extend()} was also optimized and no longer converts its
! argument into a temporary list prior to extending the base list.
\item \function{list()}, \function{tuple()}, \function{map()},
\function{filter()}, and \function{zip()} now run several times
faster with non-sequence arguments that supply a \method{__len__()}
! method. Previously, the pre-sizing optimization only applied to
! sequence arguments.
\item The methods \method{list.__getitem__()},
--- 585,606 ----
\begin{itemize}
! \item The inner loops for list and tupleslicing
were optimized and now run about one-third faster. The inner
! loops were also optimized for dictionaries with performance
boosts to \method{keys()}, \method{values()}, \method{items()},
\method{iterkeys()}, \method{itervalues()}, and \method{iteritems()}.
! \item The machinery for growing and shrinking lists was optimized for
! speed and for space efficiency. Appending and popping from lists now
! runs faster due to more efficient code paths and less frequent use of
! the underlying system \cfunction{realloc()}. List comprehensions
! also benefit. \method{list.extend()} was also optimized and no
! longer converts its argument into a temporary list before extending
! the base list.
\item \function{list()}, \function{tuple()}, \function{map()},
\function{filter()}, and \function{zip()} now run several times
faster with non-sequence arguments that supply a \method{__len__()}
! method.
\item The methods \method{list.__getitem__()},
***************
*** 686,691 ****
Several modules now take advantage of \class{collections.deque} for
! improved performance: \module{Queue}, \module{mutex}, \module{shlex}
! \module{threading}, and \module{pydoc}.
\item The \module{ConfigParser} classes have been enhanced slightly.
--- 686,691 ----
Several modules now take advantage of \class{collections.deque} for
! improved performance, such as the \module{Queue} and
! \module{threading} modules.
\item The \module{ConfigParser} classes have been enhanced slightly.
***************
*** 706,711 ****
\item The \module{itertools} module gained a
! \function{groupby(\var{iterable}\optional{, \var{func}})} function,
! inspired by the GROUP BY clause from SQL.
\var{iterable} returns a succession of elements, and the optional
\var{func} is a function that takes an element and returns a key
--- 706,710 ----
\item The \module{itertools} module gained a
! \function{groupby(\var{iterable}\optional{, \var{func}})} function.
\var{iterable} returns a succession of elements, and the optional
\var{func} is a function that takes an element and returns a key
***************
*** 733,740 ****
\end{verbatim}
! Like its SQL counterpart, \function{groupby()} is typically used with
! sorted input. The logic for \function{groupby()} is similar to the
! \UNIX{} \code{uniq} filter which makes it handy for eliminating,
! counting, or identifying duplicate elements:
\begin{verbatim}
--- 732,739 ----
\end{verbatim}
! \function{groupby()} is typically used with sorted input. The logic
! for \function{groupby()} is similar to the \UNIX{} \code{uniq} filter
! which makes it handy for eliminating, counting, or identifying
! duplicate elements:
\begin{verbatim}
***************
*** 743,752 ****
>>> letters
['a', 'a', 'a', 'a', 'a', 'b', 'b', 'c', 'd', 'r', 'r']
! >>> [k for k, g in groupby(letters)] # List unique letters
['a', 'b', 'c', 'd', 'r']
! >>> [(k, len(list(g))) for k, g in groupby(letters)] # Count letter occurences
[('a', 5), ('b', 2), ('c', 1), ('d', 1), ('r', 2)]
- >>> [k for k, g in groupby(letters) if len(list(g)) > 1] # List duplicated letters
- ['a', 'b', 'r']
\end{verbatim}
--- 742,759 ----
>>> letters
['a', 'a', 'a', 'a', 'a', 'b', 'b', 'c', 'd', 'r', 'r']
! >>> for k, g in itertools.groupby(letters):
! ... print k, list(g)
! ...
! a ['a', 'a', 'a', 'a', 'a']
! b ['b', 'b']
! c ['c']
! d ['d']
! r ['r', 'r']
! >>> # List unique letters
! >>> [k for k, g in groupby(letters)]
['a', 'b', 'c', 'd', 'r']
! >>> # Count letter occurences
! >>> [(k, len(list(g))) for k, g in groupby(letters)]
[('a', 5), ('b', 2), ('c', 1), ('d', 1), ('r', 2)]
\end{verbatim}
***************
*** 771,775 ****
This should therefore be used carefully if the leading iterator
can run far ahead of the trailing iterator in a long stream of inputs.
! If the separation is large, then it becomes preferable to use
\function{list()} instead. When the iterators track closely with one
another, \function{tee()} is ideal. Possible applications include
--- 778,782 ----
This should therefore be used carefully if the leading iterator
can run far ahead of the trailing iterator in a long stream of inputs.
! If the separation is large, then you might as well use
\function{list()} instead. When the iterators track closely with one
another, \function{tee()} is ideal. Possible applications include
More information about the Python-checkins
mailing list