diff options
| -rw-r--r-- | Doc/whatsnew/whatsnew22.tex | 59 |
1 files changed, 31 insertions, 28 deletions
diff --git a/Doc/whatsnew/whatsnew22.tex b/Doc/whatsnew/whatsnew22.tex index b849cc9..b4bd407 100644 --- a/Doc/whatsnew/whatsnew22.tex +++ b/Doc/whatsnew/whatsnew22.tex @@ -3,7 +3,7 @@ % $Id$ \title{What's New in Python 2.2} -\release{0.07} +\release{0.08} \author{A.M. Kuchling} \authoraddress{\email{akuchlin@mems-exchange.org}} \begin{document} @@ -391,22 +391,22 @@ class C: That is certainly clearer and easier to write than a pair of \method{__getattr__}/\method{__setattr__} methods that check for the -\member{size} attribute and handle it specially, while retrieving all +\member{size} attribute and handle it specially while retrieving all other attributes from the instance's \member{__dict__}. Accesses to \member{size} are also the only ones which have to perform the work of -calling a function, letting references to other attributes run at +calling a function, so references to other attributes run at their usual speed. Finally, it's possible to constrain the list of attributes that can be -referenced on an object using the new \member{__slots__} attribute. +referenced on an object using the new \member{__slots__} class attribute. Python objects are usually very dynamic; at any time it's possible to define a new attribute on an instance by just doing \code{obj.new_attr=1}. This is flexible and convenient, but this flexibility can also lead to bugs, as when you meant to write -\code{obj.template = 'a'} but make a typo and wrote +\code{obj.template = 'a'} but made a typo and wrote \code{obj.templtae} by accident. -A new-style class can define a class variable named \member{__slots__} +A new-style class can define a class attribute named \member{__slots__} to constrain the list of legal attribute names. An example will make this clear: @@ -426,6 +426,8 @@ Traceback (most recent call last): AttributeError: 'C' object has no attribute 'templtae' \end{verbatim} +Note how you get an \exception{AttributeError} on the attempt to +assign to an attribute not listed in \member{__slots__}. \subsection{Related Links} @@ -455,15 +457,15 @@ rest of the Zope Corp. team. Finally, there's the ultimate authority: the source code. Most of the machinery for the type handling is in \file{Objects/typeobject.c}, but you should only resort to it after all other avenues have been -exhausted (including posting a question to python-list or python-dev.) +exhausted, including posting a question to python-list or python-dev. %====================================================================== \section{PEP 234: Iterators} -A significant addition to 2.2 is an iteration interface at both the C -and Python levels. Objects can define how they can be looped over by -callers. +Another significant addition to 2.2 is an iteration interface at both +the C and Python levels. Objects can define how they can be looped +over by callers. In Python versions up to 2.1, the usual way to make \code{for item in obj} work is to define a \method{__getitem__()} method that looks @@ -480,14 +482,14 @@ the sixth element. It's a bit misleading when you're using this only to support \keyword{for} loops. Consider some file-like object that wants to be looped over; the \var{index} parameter is essentially meaningless, as the class probably assumes that a series of -\method{__getitem__()} calls will be made, with \var{index} +\method{__getitem__()} calls will be made with \var{index} incrementing by one each time. In other words, the presence of the \method{__getitem__()} method doesn't mean that using \code{file[5]} to randomly access the sixth element will work, though it really should. In Python 2.2, iteration can be implemented separately, and \method{__getitem__()} methods can be limited to classes that really -do support random access. The basic idea of iterators is quite +do support random access. The basic idea of iterators is simple. A new built-in function, \function{iter(obj)} or \code{iter(\var{C}, \var{sentinel})}, is used to get an iterator. \function{iter(obj)} returns an iterator for the object \var{obj}, @@ -503,10 +505,10 @@ implemented in C can implement a \code{tp_iter} function in order to return an iterator, and extension types that want to behave as iterators can define a \code{tp_iternext} function. -So what do iterators do? They have one required method, -\method{next()}, which takes no arguments and returns the next value. -When there are no more values to be returned, calling \method{next()} -should raise the \exception{StopIteration} exception. +So, after all this, what do iterators actually do? They have one +required method, \method{next()}, which takes no arguments and returns +the next value. When there are no more values to be returned, calling +\method{next()} should raise the \exception{StopIteration} exception. \begin{verbatim} >>> L = [1,2,3] @@ -527,7 +529,7 @@ StopIteration \end{verbatim} In 2.2, Python's \keyword{for} statement no longer expects a sequence; -it expects something for which \function{iter()} will return something. +it expects something for which \function{iter()} will return an iterator. For backward compatibility and convenience, an iterator is automatically constructed for sequences that don't implement \method{__iter__()} or a \code{tp_iter} slot, so \code{for i in @@ -536,6 +538,7 @@ a sequence, it's been changed to use the iterator protocol. This means you can do things like this: \begin{verbatim} +>>> L = [1,2,3] >>> i = iter(L) >>> a,b,c = i >>> a,b,c @@ -580,6 +583,7 @@ now read each line of a file using code like this: \begin{verbatim} for line in file: # do something for each line + ... \end{verbatim} Note that you can only go forward in an iterator; there's no way to @@ -607,7 +611,7 @@ 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 destroyed on exiting a function? What if you could later +weren't thrown away on exiting a function? What if you could later resume the function where it left off? This is what generators provide; they can be thought of as resumable functions. @@ -715,7 +719,7 @@ sentence := "Store it in the neighboring harbor" if (i := find("or", sentence)) > 5 then write(i) \end{verbatim} -The \function{find()} function returns the indexes at which the +In Icon the \function{find()} function returns the indexes at which the substring ``or'' is found: 3, 23, 33. In the \keyword{if} statement, \code{i} is first assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon retries it with the second value of 23. 23 @@ -728,8 +732,8 @@ Python language, but learning or using them isn't compulsory; if they don't solve any problems that you have, feel free to ignore them. One novel feature of Python's interface as compared to Icon's is that a generator's state is represented as a concrete object -that can be passed around to other functions or stored in a data -structure. +(the iterator) that can be passed around to other functions or stored +in a data structure. \begin{seealso} @@ -772,14 +776,13 @@ will now return a long integer as their result. For example: In most cases, integers and long integers will now be treated identically. You can still distinguish them with the -\function{type()} built-in function, but that's rarely needed. The -\function{int()} constructor will now return a long integer if the value -is large enough. +\function{type()} built-in function, but that's rarely needed. \begin{seealso} \seepep{237}{Unifying Long Integers and Integers}{Written by -Moshe Zadka and Guido van Rossum. Implemented mostly by Guido van Rossum.} +Moshe Zadka and Guido van Rossum. Implemented mostly by Guido van +Rossum.} \end{seealso} @@ -787,7 +790,7 @@ Moshe Zadka and Guido van Rossum. Implemented mostly by Guido van Rossum.} %====================================================================== \section{PEP 238: Changing the Division Operator} -The most controversial change in Python 2.2 is the start of an effort +The most controversial change in Python 2.2 heralds the start of an effort to fix an old design flaw that's been in Python from the beginning. Currently Python's division operator, \code{/}, behaves like C's division operator when presented with two integer arguments: it @@ -800,7 +803,7 @@ the possible types of the operands. (The controversy is over whether this is \emph{really} a design flaw, and whether it's worth breaking existing code to fix this. It's -caused endless discussions on python-dev and in July erupted into an +caused endless discussions on python-dev, and in July 2001 erupted into an storm of acidly sarcastic postings on \newsgroup{comp.lang.python}. I won't argue for either side here and will stick to describing what's implemented in 2.2. Read \pep{238} for a summary of arguments and @@ -825,7 +828,7 @@ Here are the changes 2.2 introduces: \item A new operator, \code{//}, is the floor division operator. (Yes, we know it looks like \Cpp's comment symbol.) \code{//} -\emph{always} returns the floor divison no matter what the types of +\emph{always} performs floor division no matter what the types of its operands are, so \code{1 // 2} is 0 and \code{1.0 // 2.0} is also 0.0. |