[Py-howto-checkins] CVS: pyhowto python-22.tex,1.31,1.32

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

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

Modified Files:
	python-22.tex 
Log Message:
A bunch of minor rewordings


Index: python-22.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-22.tex,v
retrieving revision 1.31
retrieving revision 1.32
diff -C2 -r1.31 -r1.32
*** python-22.tex	2001/09/28 20:46:46	1.31
--- python-22.tex	2001/10/22 02:00:11	1.32
***************
*** 39,45 ****
  rationale for a change, refer to the PEP for a particular new feature.
  
  
- The final release of Python 2.2 is planned for October 2001.
- 
  \begin{seealso}
  
--- 39,44 ----
  rationale for a change, refer to the PEP for a particular new feature.
  
+ The final release of Python 2.2 is planned for December 2001.
  
  \begin{seealso}
  
***************
*** 91,105 ****
  \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 \code{file[5]} 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
! simple.  A new built-in function, \function{iter(obj)}, returns an
! iterator for the object \var{obj}.  (It can also take two arguments:
! \code{iter(\var{C}, \var{sentinel})} will call the callable \var{C},
! until it returns \var{sentinel}, which will signal that the iterator
! is done.  This form probably won't be used very often.)
  
  Python classes can define an \method{__iter__()} method, which should
--- 90,105 ----
  \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
! 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},
! while \code{iter(\var{C}, \var{sentinel})} returns an iterator that
! will invoke the callable object \var{C} until it returns
! \var{sentinel} to signal that the iterator is done.  
  
  Python classes can define an \method{__iter__()} method, which should
***************
*** 136,140 ****
  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
  \method{__iter__()} or a \code{tp_iter} slot, so \code{for i in
--- 136,140 ----
  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
  \method{__iter__()} or a \code{tp_iter} slot, so \code{for i in
***************
*** 183,187 ****
  \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
--- 183,186 ----
***************
*** 213,217 ****
  
  You're doubtless familiar with how function calls work in Python or
! C.  When you call a function, it gets a private area where its local
  variables are created.  When the function reaches a \keyword{return}
  statement, the local variables are destroyed and the resulting value
--- 212,216 ----
  
  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
***************
*** 233,237 ****
  function containing a \keyword{yield} statement is a generator
  function; this is detected by Python's bytecode compiler which
! compiles the function specially.  Because a new keyword was
  introduced, generators must be explicitly enabled in a module by
  including a \code{from __future__ import generators} statement near
--- 232,236 ----
  function containing a \keyword{yield} statement is a generator
  function; this is detected by Python's bytecode compiler which
! compiles the function specially as a result.  Because a new keyword was
  introduced, generators must be explicitly enabled in a module by
  including a \code{from __future__ import generators} statement near
***************
*** 241,248 ****
  When you call a generator function, it doesn't return a single value;
  instead it returns a generator object that supports the iterator
! interface.  On executing the \keyword{yield} statement, the generator
  outputs the value of \code{i}, similar to a \keyword{return}
  statement.  The big difference between \keyword{yield} and a
! \keyword{return} statement is that, on reaching a \keyword{yield} the
  generator's state of execution is suspended and local variables are
  preserved.  On the next call to the generator's \code{.next()} method,
--- 240,247 ----
  When you call a generator function, it doesn't return a single value;
  instead it returns a generator object that supports the iterator
! protocol.  On executing the \keyword{yield} statement, the generator
  outputs the value of \code{i}, similar to a \keyword{return}
  statement.  The big difference between \keyword{yield} and a
! \keyword{return} statement is that on reaching a \keyword{yield} the
  generator's state of execution is suspended and local variables are
  preserved.  On the next call to the generator's \code{.next()} method,
***************
*** 316,320 ****
  The idea of generators comes from other programming languages,
  especially Icon (\url{http://www.cs.arizona.edu/icon/}), where the
! idea of generators is central to the language.  In Icon, every
  expression and function call behaves like a generator.  One example
  from ``An Overview of the Icon Programming Language'' at
--- 315,319 ----
  The idea of generators comes from other programming languages,
  especially Icon (\url{http://www.cs.arizona.edu/icon/}), where the
! idea of generators is central.  In Icon, every
  expression and function call behaves like a generator.  One example
  from ``An Overview of the Icon Programming Language'' at
***************
*** 338,343 ****
  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.
! This is different from Icon where the idea of generators is a basic
! concept.  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
--- 337,341 ----
  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
***************
*** 359,363 ****
  are 32-bit values on most machines, and long integers, which can be of
  arbitrary size, was becoming an annoyance.  For example, on platforms
! that support large files (files larger than \code{2**32} bytes), the
  \method{tell()} method of file objects has to return a long integer.
  However, there were various bits of Python that expected plain
--- 357,361 ----
  are 32-bit values on most machines, and long integers, which can be of
  arbitrary size, was becoming an annoyance.  For example, on platforms
! that support files larger than \code{2**32} bytes, the
  \method{tell()} method of file objects has to return a long integer.
  However, there were various bits of Python that expected plain
***************
*** 386,390 ****
  identically.  You can still distinguish them with the
  \function{type()} built-in function, but that's rarely needed.  The
! \function{int()} function will now return a long integer if the value
  is large enough.  
  
--- 384,388 ----
  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.  
  
***************
*** 403,409 ****
  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
--- 401,407 ----
  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
! a 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
***************
*** 415,420 ****
  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
--- 413,419 ----
  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 
! implemented in 2.2.  Read PEP 238 for a summary of arguments and
! counter-arguments.)  
  
  Because this change might break code, it's being introduced very
***************
*** 422,426 ****
  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{/}
--- 421,425 ----
  complete until Python 3.0.
  
! First, I'll borrow 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{/}
***************
*** 482,489 ****
  \function{unichr()} to raise a \exception{ValueError} exception.
  
  All this is the province of the still-unimplemented PEP 261, ``Support
  for `wide' Unicode characters''; consult it for further details, and
  please offer comments on the PEP and on your experiences with the
! 2.2 alpha releases.
  % XXX update previous line once 2.2 reaches beta.
  
--- 481,489 ----
  \function{unichr()} to raise a \exception{ValueError} exception.
  
+ % XXX is this still unimplemented?
  All this is the province of the still-unimplemented PEP 261, ``Support
  for `wide' Unicode characters''; consult it for further details, and
  please offer comments on the PEP and on your experiences with the
! 2.2 beta releases.
  % XXX update previous line once 2.2 reaches beta.
  
***************
*** 520,523 ****
--- 520,527 ----
  \end{verbatim}
  
+ To convert a class instance to Unicode, a \method{__unicode__} method
+ can be defined, analogous to \method{__str__}.
+ % XXX who implemented that?
+ 
  \method{encode()} and \method{decode()} were implemented by
  Marc-Andr\'e Lemburg.  The changes to support using UCS-4 internally
***************
*** 537,541 ****
  feature, to be enabled by a \code{from __future__ import
  nested_scopes} directive.  In 2.2 nested scopes no longer need to be
! specially enabled, but are always enabled.  The rest of this section
  is a copy of the description of nested scopes from my ``What's New in
  Python 2.1'' document; if you read it when 2.1 came out, you can skip
--- 541,545 ----
  feature, to be enabled by a \code{from __future__ import
  nested_scopes} directive.  In 2.2 nested scopes no longer need to be
! specially enabled, and are now always present.  The rest of this section
  is a copy of the description of nested scopes from my ``What's New in
  Python 2.1'' document; if you read it when 2.1 came out, you can skip
***************
*** 642,650 ****
  
    \item The \module{xmlrpclib} module was contributed to the standard
!   library by Fredrik Lundh.  It provides support for writing XML-RPC
!   clients; XML-RPC is a simple remote procedure call protocol built on
    top of HTTP and XML. For example, the following snippet retrieves a
!   list of RSS channels from the O'Reilly Network, and then retrieves a
!   list of the recent headlines for one channel:
  
  \begin{verbatim}
--- 646,654 ----
  
    \item The \module{xmlrpclib} module was contributed to the standard
!   library by Fredrik Lundh, provding support for writing XML-RPC
!   clients.  XML-RPC is a simple remote procedure call protocol built on
    top of HTTP and XML. For example, the following snippet retrieves a
!   list of RSS channels from the O'Reilly Network, and then 
!   lists the recent headlines for one channel:
  
  \begin{verbatim}
***************
*** 674,677 ****
--- 678,685 ----
    algorithm described by \rfc{2104}.
  
+   \item The Python profiler has been extensively reworked and various
+   errors in its output have been corrected.  (Contributed by Fred
+   Fred~L. Drake, Jr. and Tim Peters.)
+  
    \item The \module{socket} module can be compiled to support IPv6;
    specify the \longprogramopt{enable-ipv6} option to Python's configure
***************
*** 685,690 ****
  
    \item In the interpreter's interactive mode, there's a new built-in
!   function \function{help()}, that uses the \module{pydoc} module
!   introduced in Python 2.1 to provide interactive.
    \code{help(\var{object})} displays any available help text about
    \var{object}.  \code{help()} with no argument puts you in an online
--- 693,698 ----
  
    \item In the interpreter's interactive mode, there's a new built-in
!   function \function{help()} that uses the \module{pydoc} module
!   introduced in Python 2.1 to provide interactive help.
    \code{help(\var{object})} displays any available help text about
    \var{object}.  \code{help()} with no argument puts you in an online
***************
*** 727,736 ****
    of legal characters defined by the current locale.  The buggy
    modules have all been fixed to use \constant{ascii_letters} instead.
!   (Reported by an unknown person; fixed by Fred L. Drake, Jr.)
  
    \item The \module{mimetypes} module now makes it easier to use
    alternative MIME-type databases by the addition of a
    \class{MimeTypes} class, which takes a list of filenames to be
!   parsed.  (Contributed by Fred L. Drake, Jr.)
  
    \item A \class{Timer} class was added to the \module{threading}
--- 735,744 ----
    of legal characters defined by the current locale.  The buggy
    modules have all been fixed to use \constant{ascii_letters} instead.
!   (Reported by an unknown person; fixed by Fred~L. Drake, Jr.)
  
    \item The \module{mimetypes} module now makes it easier to use
    alternative MIME-type databases by the addition of a
    \class{MimeTypes} class, which takes a list of filenames to be
!   parsed.  (Contributed by Fred~L. Drake, Jr.)
  
    \item A \class{Timer} class was added to the \module{threading}
***************
*** 745,749 ****
  
  Some of the changes only affect people who deal with the Python
! interpreter at the C level, writing Python extension modules,
  embedding the interpreter, or just hacking on the interpreter itself.
  If you only write Python code, none of the changes described here will
--- 753,757 ----
  
  Some of the changes only affect people who deal with the Python
! interpreter at the C level because they're writing Python extension modules,
  embedding the interpreter, or just hacking on the interpreter itself.
  If you only write Python code, none of the changes described here will
***************
*** 754,759 ****
    \item Profiling and tracing functions can now be implemented in C,
    which can operate at much higher speeds than Python-based functions
!   and should reduce the overhead of enabling profiling and tracing, so
!   it will be of interest to authors of development environments for
    Python.  Two new C functions were added to Python's API,
    \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}.
--- 762,767 ----
    \item Profiling and tracing functions can now be implemented in C,
    which can operate at much higher speeds than Python-based functions
!   and should reduce the overhead of profiling and tracing.  This 
!   will be of interest to authors of development environments for
    Python.  Two new C functions were added to Python's API,
    \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}.
***************
*** 780,784 ****
    which assumes that 8-bit strings are in Python's default ASCII
    encoding and converts them to the specified new encoding.
!   (Contributed by M.-A. Lemburg.)
   
    \item Two new flags \constant{METH_NOARGS} and \constant{METH_O} are
--- 788,793 ----
    which assumes that 8-bit strings are in Python's default ASCII
    encoding and converts them to the specified new encoding.
!   (Contributed by M.-A. Lemburg, and used for the MBCS support on
!   Windows described in the following section.)
   
    \item Two new flags \constant{METH_NOARGS} and \constant{METH_O} are
***************
*** 792,796 ****
  \item
     Two new wrapper functions, \cfunction{PyOS_snprintf()} and
!    \cfunction{PyOS_vsnprintf()} were added.  which provide a
     cross-platform implementations for the relatively new
     \cfunction{snprintf()} and \cfunction{vsnprintf()} C lib APIs. In
--- 801,805 ----
  \item
     Two new wrapper functions, \cfunction{PyOS_snprintf()} and
!    \cfunction{PyOS_vsnprintf()} were added to provide 
     cross-platform implementations for the relatively new
     \cfunction{snprintf()} and \cfunction{vsnprintf()} C lib APIs. In
***************
*** 833,837 ****
  Most of the MacPython toolbox modules, which interface to MacOS APIs
  such as windowing, QuickTime, scripting, etc. have been ported to OS
! X, but they've been left commented out in setup.py.  People who want
  to experiment with these modules can uncomment them manually.
  
--- 842,846 ----
  Most of the MacPython toolbox modules, which interface to MacOS APIs
  such as windowing, QuickTime, scripting, etc. have been ported to OS
! X, but they've been left commented out in \filename{setup.py}.  People who want
  to experiment with these modules can uncomment them manually.
  
***************
*** 854,858 ****
  %can uncomment them. Gestalt and Internet Config modules are enabled by
  %default.
- 
    
    \item Keyword arguments passed to builtin functions that don't take them
--- 863,866 ----
***************
*** 860,863 ****
--- 868,877 ----
    message "\var{function} takes no keyword arguments".
    
+   \item Weak references, added in Python 2.1 as an extension module,
+   are now part of the core because they're used in the implementation
+   of new-style classes.  The \exception{ReferenceError} exception has
+   therefore moved from the \module{weakref} module to become a
+   built-in exception.
+ 
    \item A new script, \file{Tools/scripts/cleanfuture.py} by Tim
    Peters, automatically removes obsolete \code{__future__} statements
***************
*** 866,872 ****
    \item The new license introduced with Python 1.6 wasn't
    GPL-compatible.  This is fixed by some minor textual changes to the
!   2.2 license, so Python can now be embedded inside a GPLed program
!   again.  The license changes were also applied to the Python 2.0.1
!   and 2.1.1 releases.
  
    \item When presented with a Unicode filename on Windows, Python will
--- 880,888 ----
    \item The new license introduced with Python 1.6 wasn't
    GPL-compatible.  This is fixed by some minor textual changes to the
!   2.2 license, so it's now legal to embed Python inside a GPLed
!   program again.  Note that Python itself is not GPLed, but instead is
!   under a license that's essentially equivalent to the BSD license,
!   same as it always was.  The license changes were also applied to the
!   Python 2.0.1 and 2.1.1 releases.
  
    \item When presented with a Unicode filename on Windows, Python will
***************
*** 901,906 ****
    contains objects that sneakily changed their hash value, or mutated
    the dictionary they were contained in. For a while python-dev fell
!   into a gentle rhythm of Michael Hudson finding a case that dump
!   core, Tim Peters fixing it, Michael finding another case, and round
    and round it went.   
  
--- 917,922 ----
    contains objects that sneakily changed their hash value, or mutated
    the dictionary they were contained in. For a while python-dev fell
!   into a gentle rhythm of Michael Hudson finding a case that dumped
!   core, Tim Peters fixing the bug, Michael finding another case, and round
    and round it went.   
  
***************
*** 942,946 ****
  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, Stephen Hansen, Jack Jansen, Marc-Andr\'e Lemburg, Tim Peters, Neil
  Schemenauer, Guido van Rossum.
--- 958,962 ----
  The author would like to thank the following people for offering
  suggestions and corrections to various drafts of this article: Fred
! Bremmer, Keith Briggs, Andrew Dalke, Fred~L. Drake, Jr., Carel Fellinger, Mark
  Hammond, Stephen Hansen, Jack Jansen, Marc-Andr\'e Lemburg, Tim Peters, Neil
  Schemenauer, Guido van Rossum.