[Py-howto-checkins] CVS: pyhowto python-22.tex,1.20,1.21

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

Modified Files:
	python-22.tex 
Log Message:
Add section on PEP 238 changes
Minor grammatical changes, reformattings, and an error fix from Keith Briggs

Index: python-22.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -r1.20 -r1.21
*** python-22.tex	2001/08/07 14:28:58	1.20
--- python-22.tex	2001/08/11 03:06:50	1.21
***************
*** 13,19 ****

  {\large This document is a draft, and is subject to change until the
! final version of Python 2.2 is released.  Currently it's not up to
! date at all.  Please send any comments, bug reports, or questions, no
! matter how minor, to \email{aku...@me...}.  }

  This article explains the new features in Python 2.2.  Python 2.2
--- 13,20 ----

  {\large This document is a draft, and is subject to change until the
! final version of Python 2.2 is released.  Currently it's up to date
! for Python 2.2 alpha 1.  Please send any comments, bug reports, or
! questions, no matter how minor, to \email{aku...@me...}.
! }

  This article explains the new features in Python 2.2.  Python 2.2
***************
*** 136,142 ****
  \end{verbatim}

! Iterator support has been added to some of Python's basic types.  The
! \keyword{in} operator now works on dictionaries, so \code{\var{key} in
! dict} is now equivalent to \code{dict.has_key(\var{key})}.
  Calling \function{iter()} on a dictionary will return an iterator
  which loops over its keys:
--- 137,141 ----
  \end{verbatim}

! Iterator support has been added to some of Python's basic types.  
  Calling \function{iter()} on a dictionary will return an iterator
  which loops over its keys:
***************
*** 165,171 ****
  values, or key/value pairs, you can explicitly call the
  \method{iterkeys()}, \method{itervalues()}, or \method{iteritems()}
! methods to get an appropriate iterator.  

! Files also provide an iterator, which calls its \method{readline()}
  method until there are no more lines in the file.  This means you can
  now read each line of a file using code like this:
--- 164,174 ----
  values, or key/value pairs, you can explicitly call the
  \method{iterkeys()}, \method{itervalues()}, or \method{iteritems()}
! methods to get an appropriate iterator.  In a minor related change,
! the \keyword{in} operator now works on dictionaries, so
! \code{\var{key} in dict} is now equivalent to
! \code{dict.has_key(\var{key})}.

! 
! Files also provide an iterator, which calls the \method{readline()}
  method until there are no more lines in the file.  This means you can
  now read each line of a file using code like this:
***************
*** 337,340 ****
--- 340,413 ----

  %======================================================================
+ \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
+ division operator when presented with two integer arguments.  It
+ returns an integer result that's truncated down when there would be
+ fractional part.  For example, \code{3/2} is 1, not 1.5, and
+ \code{(-1)/2} is -1, not -0.5.  This means that the results of divison
+ can vary unexpectedly depending on the type of the two operands and
+ because Python is dynamically typed, it can be difficult to determine
+ 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
+ storm of acidly sarcastic postings on \newsgroup{comp.lang.python}. I
+ won't argue for either side here; read PEP 238 for a summary of
+ arguments and counter-arguments.)
+ 
+ Because this change might break code, it's being introduced very
+ gradually.  Python 2.2 begins the transition, but the switch won't be
+ complete until Python 3.0.
+ 
+ First, some terminology from PEP 238.  ``True division'' is the
+ division that most non-programmers are familiar with: 3/2 is 1.5, 1/4
+ is 0.25, and so forth.  ``Floor division'' is what Python's \code{/}
+ operator currently does when given integer operands; the result is the
+ floor of the value returned by true division.  ``Classic division'' is
+ the current mixed behaviour of \code{/}; it returns the result of
+ floor division when the operands are integers, and returns the result
+ of true division when one of the operands is a floating-point number.
+ 
+ Here are the changes 2.2 introduces:
+ 
+ \begin{itemize}
+ 
+ \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.
+ 
+ \code{//} is always available in Python 2.2; you don't need to enable
+ it using a \code{__future__} statement.  
+ 
+ \item By including a \code{from __future__ import true_division} in a
+ module, the \code{/} operator will be changed to return the result of
+ true division, so \code{1/2} is 0.5.  Without the \code{__future__}
+ statement, \code{/} still means classic division.  The default meaning
+ of \code{/} will not change until Python 3.0.  
+ 
+ \item Classes can define methods called \method{__truediv__} and
+ \method{__floordiv__} to overload the two division operators.  At the
+ C level, there are also slots in the \code{PyNumberMethods} structure
+ so extension types can define the two operators.
+ 
+ % XXX a warning someday?
+ 
+ \end{itemize}
+ 
+ \begin{seealso}
+ 
+ \seepep{238}{Changing the Division Operator}{Written by Moshe Zadka and 
+ Guido van Rossum.  Implemented by Guido van Rossum..}
+ 
+ \end{seealso}
+ 
+ 
+ %======================================================================
  \section{Unicode Changes}

***************
*** 733,738 ****
  The author would like to thank the following people for offering
  suggestions and corrections to various drafts of this article: Fred
! Bremmer, Keith Briggs, Fred L. Drake, Jr., Mark Hammond, Marc-Andr\'e
! Lemburg, Tim Peters, Neil Schemenauer, Guido van Rossum.

  \end{document}
--- 806,812 ----
  The author would like to thank the following people for offering
  suggestions and corrections to various drafts of this article: Fred
! Bremmer, Keith Briggs, Fred L. Drake, Jr., Carel Fellinger, Mark
! Hammond, Marc-Andr\'e Lemburg, Tim Peters, Neil Schemenauer, Guido van
! Rossum.

  \end{document}