[Py-howto-checkins] CVS: pyhowto python-22.tex,1.42,1.43

[A.M. K. <aku...@us...>]

Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv9600

Modified Files:
	python-22.tex 
Log Message:
Various minor rewrites
Bump version number


Index: python-22.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v
retrieving revision 1.42
retrieving revision 1.43
diff -C2 -r1.42 -r1.43
*** python-22.tex	2001/10/30 14:22:11	1.42
--- python-22.tex	2001/10/30 14:35:03	1.43
***************
*** 4,8 ****
  
  \title{What's New in Python 2.2}
! \release{0.07}
  \author{A.M. Kuchling}
  \authoraddress{\email{aku...@me...}}
--- 4,8 ----
  
  \title{What's New in Python 2.2}
! \release{0.08}
  \author{A.M. Kuchling}
  \authoraddress{\email{aku...@me...}}
***************
*** 392,411 ****
  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
  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
  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.
  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.templtae} by accident.  
  
! A new-style class can define a class variable named \member{__slots__}
  to constrain the list of legal attribute names.  An example will make
  this clear:
--- 392,411 ----
  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
  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, 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__} 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 made a typo and wrote
  \code{obj.templtae} by accident.  
  
! 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:
***************
*** 427,430 ****
--- 427,432 ----
  \end{verbatim}
  
+ Note how you get an \exception{AttributeError} on the attempt to
+ assign to an attribute not listed in \member{__slots__}.
  
  
***************
*** 456,460 ****
  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.)
  
  
--- 458,462 ----
  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. 
  
  
***************
*** 462,468 ****
  \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.
  
  In Python versions up to 2.1, the usual way to make \code{for item in
--- 464,470 ----
  \section{PEP 234: Iterators}
  
! 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
***************
*** 481,485 ****
  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}
  incrementing by one each time.  In other words, the presence of the
  \method{__getitem__()} method doesn't mean that using \code{file[5]} 
--- 483,487 ----
  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}
  incrementing by one each time.  In other words, the presence of the
  \method{__getitem__()} method doesn't mean that using \code{file[5]} 
***************
*** 488,492 ****
  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
  simple.  A new built-in function, \function{iter(obj)} or
  \code{iter(\var{C}, \var{sentinel})}, is used to get an iterator.
--- 490,494 ----
  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 
  simple.  A new built-in function, \function{iter(obj)} or
  \code{iter(\var{C}, \var{sentinel})}, is used to get an iterator.
***************
*** 504,511 ****
  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.
  
  \begin{verbatim}
--- 506,513 ----
  iterators can define a \code{tp_iternext} function.
  
! 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}
***************
*** 528,532 ****
  
  In 2.2, Python's \keyword{for} statement no longer expects a sequence;
! it expects something for which \function{iter()} will return something.
  For backward compatibility and convenience, an iterator is
  automatically constructed for sequences that don't implement
--- 530,534 ----
  
  In 2.2, Python's \keyword{for} statement no longer expects a sequence;
! 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
***************
*** 537,540 ****
--- 539,543 ----
  
  \begin{verbatim}
+ >>> L = [1,2,3]
  >>> i = iter(L)
  >>> a,b,c = i
***************
*** 581,584 ****
--- 584,588 ----
  for line in file:
      # do something for each line
+     ...
  \end{verbatim}
  
***************
*** 608,612 ****
  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
  resume the function where it left off?  This is what generators
  provide; they can be thought of as resumable functions.
--- 612,616 ----
  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
  provide; they can be thought of as resumable functions.
***************
*** 716,720 ****
  \end{verbatim}
  
! 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
--- 720,724 ----
  \end{verbatim}
  
! 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
***************
*** 729,734 ****
  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.
  
  \begin{seealso}
--- 733,738 ----
  One novel feature of Python's interface as compared to
  Icon's is that a generator's state is represented as a concrete object
! (the iterator) that can be passed around to other functions or stored
! in a data structure.
  
  \begin{seealso}
***************
*** 773,784 ****
  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.  
  
  \begin{seealso}
  
  \seepep{237}{Unifying Long Integers and Integers}{Written by
! Moshe Zadka and Guido van Rossum.  Implemented mostly by Guido van Rossum.}
  
  \end{seealso}
--- 777,787 ----
  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.  
  
  \begin{seealso}
  
  \seepep{237}{Unifying Long Integers and Integers}{Written by
! Moshe Zadka and Guido van Rossum.  Implemented mostly by Guido van
! Rossum.}
  
  \end{seealso}
***************
*** 788,792 ****
  \section{PEP 238: Changing the Division Operator}
  
! The most controversial change in Python 2.2 is 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
--- 791,795 ----
  \section{PEP 238: Changing the Division Operator}
  
! 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
***************
*** 801,805 ****
  (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
  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 
--- 804,808 ----
  (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 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 
***************
*** 826,830 ****
  \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
  its operands are, so \code{1 // 2} is 0 and \code{1.0 // 2.0} is also
  0.0.
--- 829,833 ----
  \item A new operator, \code{//}, is the floor division operator.
  (Yes, we know it looks like \Cpp's comment symbol.)  \code{//}
! \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.