[Python-checkins] CVS: python/dist/src/Doc/tut tut.tex,1.117,1.118

Fred L. Drake python-dev@python.org
Fri, 29 Sep 2000 08:17:40 -0700


Update of /cvsroot/python/python/dist/src/Doc/tut
In directory slayer.i.sourceforge.net:/tmp/cvs-serv17463/tut

Modified Files:
	tut.tex 
Log Message:
Spelling:  internalization --> internationalization
Fixed displays of the interactive prompt in running text.
These close SourceForge bug #115658.

Also:

Updated discussion of tuple unpacking to reflect the general ability
to unpack any sequence type.  Explained that it is possible to create
tuples which contain mutable values, and noted in the dictionary
section that such tuples cannot be used as keys.

Noted that .pyc and .pyo files can be run directly when provided as
the script parameter to the interpreter, and slightly clarified
comments about using modules with only the byte compiled code.

Removed some XXX comments that are no longer relevant.
Removed commented-out paragraph about __private names being experimental.

Adjusted markup for consistency in some places.


Index: tut.tex
===================================================================
RCS file: /cvsroot/python/python/dist/src/Doc/tut/tut.tex,v
retrieving revision 1.117
retrieving revision 1.118
diff -C2 -r1.117 -r1.118
*** tut.tex	2000/09/22 04:12:27	1.117
--- tut.tex	2000/09/29 15:17:36	1.118
***************
*** 239,243 ****
  \emph{interactive mode}.  In this mode it prompts for the next command
  with the \emph{primary prompt}, usually three greater-than signs
! (\samp{>>>~}); for continuation lines it prompts with the
  \emph{secondary prompt}, by default three dots (\samp{...~}).
  The interpreter prints a welcome message stating its version number
--- 239,243 ----
  \emph{interactive mode}.  In this mode it prompts for the next command
  with the \emph{primary prompt}, usually three greater-than signs
! (\samp{>\code{>}>~}); for continuation lines it prompts with the
  \emph{secondary prompt}, by default three dots (\samp{...~}).
  The interpreter prints a welcome message stating its version number
***************
*** 341,345 ****
  
  In the following examples, input and output are distinguished by the
! presence or absence of prompts (\samp{>>>~} and \samp{...~}): to repeat
  the example, you must type everything after the prompt, when the
  prompt appears; lines that do not begin with a prompt are output from
--- 341,345 ----
  
  In the following examples, input and output are distinguished by the
! presence or absence of prompts (\samp{>\code{>}>~} and \samp{...~}): to repeat
  the example, you must type everything after the prompt, when the
  prompt appears; lines that do not begin with a prompt are output from
***************
*** 373,377 ****
  
  Let's try some simple Python commands.  Start the interpreter and wait
! for the primary prompt, \samp{>>> }.  (It shouldn't take long.)
  
  \subsection{Numbers \label{numbers}}
--- 373,377 ----
  
  Let's try some simple Python commands.  Start the interpreter and wait
! for the primary prompt, \samp{>\code{>}>~}.  (It shouldn't take long.)
  
  \subsection{Numbers \label{numbers}}
***************
*** 421,425 ****
  0
  \end{verbatim}
! %
  There is full support for floating point; operators with mixed type
  operands convert the integer operand to floating point:
--- 421,425 ----
  0
  \end{verbatim}
! 
  There is full support for floating point; operators with mixed type
  operands convert the integer operand to floating point:
***************
*** 431,435 ****
  3.5
  \end{verbatim}
! %
  Complex numbers are also supported; imaginary numbers are written with
  a suffix of \samp{j} or \samp{J}.  Complex numbers with a nonzero
--- 431,435 ----
  3.5
  \end{verbatim}
! 
  Complex numbers are also supported; imaginary numbers are written with
  a suffix of \samp{j} or \samp{J}.  Complex numbers with a nonzero
***************
*** 449,453 ****
  (1.5+0.5j)
  \end{verbatim}
! %
  Complex numbers are always represented as two floating point numbers,
  the real and imaginary part.  To extract these parts from a complex
--- 449,453 ----
  (1.5+0.5j)
  \end{verbatim}
! 
  Complex numbers are always represented as two floating point numbers,
  the real and imaginary part.  To extract these parts from a complex
***************
*** 461,465 ****
  0.5
  \end{verbatim}
! %
  The conversion functions to floating point and integer
  (\function{float()}, \function{int()} and \function{long()}) don't
--- 461,465 ----
  0.5
  \end{verbatim}
! 
  The conversion functions to floating point and integer
  (\function{float()}, \function{int()} and \function{long()}) don't
***************
*** 479,483 ****
  1.58113883008
  \end{verbatim}
! %
  In interactive mode, the last printed expression is assigned to the
  variable \code{_}.  This means that when you are using Python as a
--- 479,483 ----
  1.58113883008
  \end{verbatim}
! 
  In interactive mode, the last printed expression is assigned to the
  variable \code{_}.  This means that when you are using Python as a
***************
*** 750,756 ****
  typically bound to a code page which mapped the ordinals to script
  characters. This lead to very much confusion especially with respect
! to internalization (usually written as \samp{i18n} --- \character{i} +
! 18 characters + \character{n}) of software. Unicode solves these
! problems by defining one code page for all scripts.
  
  Creating Unicode strings in Python is just as simple as creating
--- 750,756 ----
  typically bound to a code page which mapped the ordinals to script
  characters. This lead to very much confusion especially with respect
! to internationalization (usually written as \samp{i18n} ---
! \character{i} + 18 characters + \character{n}) of software.  Unicode
! solves these problems by defining one code page for all scripts.
  
  Creating Unicode strings in Python is just as simple as creating
***************
*** 1168,1171 ****
--- 1168,1172 ----
  \end{verbatim}
  
+ 
  \section{\keyword{pass} Statements \label{pass}}
  
***************
*** 1181,1184 ****
--- 1182,1186 ----
  \end{verbatim}
  
+ 
  \section{Defining Functions \label{functions}}
  
***************
*** 1278,1282 ****
  [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
  \end{verbatim}
! %
  This example, as usual, demonstrates some new Python features:
  
--- 1280,1284 ----
  [1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
  \end{verbatim}
! 
  This example, as usual, demonstrates some new Python features:
  
***************
*** 1468,1471 ****
--- 1470,1474 ----
  \end{verbatim}
  
+ 
  \subsection{Arbitrary Argument Lists \label{arbitraryArgs}}
  
***************
*** 1754,1757 ****
--- 1757,1761 ----
  \end{verbatim}
  
+ 
  \subsection{List Comprehensions}
  
***************
*** 1796,1799 ****
--- 1800,1804 ----
  \end{verbatim}
  
+ 
  \section{The \keyword{del} statement \label{del}}
  
***************
*** 1824,1827 ****
--- 1829,1833 ----
  \keyword{del} later.
  
+ 
  \section{Tuples and Sequences \label{tuples}}
  
***************
*** 1856,1860 ****
  possible to assign to the individual items of a tuple (you can
  simulate much of the same effect with slicing and concatenation,
! though).
  
  A special problem is the construction of tuples containing 0 or 1
--- 1862,1867 ----
  possible to assign to the individual items of a tuple (you can
  simulate much of the same effect with slicing and concatenation,
! though).  It is also possible to create tuples which contain mutable
! objects, such as lists.
  
  A special problem is the construction of tuples containing 0 or 1
***************
*** 1885,1907 ****
  \end{verbatim}
  
! This is called, appropriately enough, \emph{tuple unpacking}.  Tuple
! unpacking requires that the list of variables on the left have the same
! number of elements as the length of the tuple.  Note that multiple
! assignment is really just a combination of tuple packing and tuple
! unpacking!
! 
! % XXX This is no longer necessary!
! Occasionally, the corresponding operation on lists is useful: \emph{list
! unpacking}.  This is supported by enclosing the list of variables in
! square brackets:
  
! \begin{verbatim}
! >>> a = ['spam', 'eggs', 100, 1234]
! >>> [a1, a2, a3, a4] = a
! \end{verbatim}
  
  % XXX Add a bit on the difference between tuples and lists.
- % XXX Also explain that a tuple can *contain* a mutable object!
  
  \section{Dictionaries \label{dictionaries}}
  
--- 1892,1907 ----
  \end{verbatim}
  
! This is called, appropriately enough, \emph{sequence unpacking}.
! Sequence unpacking requires that the list of variables on the left
! have the same number of elements as the length of the sequence.  Note
! that multiple assignment is really just a combination of tuple packing
! and sequence unpacking!
  
! There is a small bit of asymmetry here:  packing multiple values
! always creates a tuple, and unpacking works for any sequence.
  
  % XXX Add a bit on the difference between tuples and lists.
  
+ 
  \section{Dictionaries \label{dictionaries}}
  
***************
*** 1912,1920 ****
  which can be any immutable type; strings and numbers can always be
  keys.  Tuples can be used as keys if they contain only strings,
! numbers, or tuples.  You can't use lists as keys, since lists can be
! modified in place using their \code{append()} method.
  
  It is best to think of a dictionary as an unordered set of
! \emph{key:value} pairs, with the requirement that the keys are unique
  (within one dictionary).
  A pair of braces creates an empty dictionary: \code{\{\}}.
--- 1912,1923 ----
  which can be any immutable type; strings and numbers can always be
  keys.  Tuples can be used as keys if they contain only strings,
! numbers, or tuples; if a tuple contains any mutable object either
! directly or indirectly, it cannot be used as a key.  You can't use
! lists as keys, since lists can be modified in place using their
! \method{append()} and \method{extend()} methods, as well as slice and
! indexed assignments.
  
  It is best to think of a dictionary as an unordered set of
! \emph{key: value} pairs, with the requirement that the keys are unique
  (within one dictionary).
  A pair of braces creates an empty dictionary: \code{\{\}}.
***************
*** 2002,2005 ****
--- 2005,2009 ----
  \code{==} was intended.
  
+ 
  \section{Comparing Sequences and Other Types \label{comparing}}
  
***************
*** 2103,2107 ****
  'fibo'
  \end{verbatim}
! %
  If you intend to use a function often you can assign it to a local name:
  
--- 2107,2111 ----
  'fibo'
  \end{verbatim}
! 
  If you intend to use a function often you can assign it to a local name:
  
***************
*** 2165,2171 ****
  (\code{_}).
  
- \subsection{The Module Search Path \label{searchPath}}
  
! % XXX Need to document that a lone .pyc/.pyo is acceptable too!
  
  \indexiii{module}{search}{path}
--- 2169,2174 ----
  (\code{_}).
  
  
! \subsection{The Module Search Path \label{searchPath}}
  
  \indexiii{module}{search}{path}
***************
*** 2239,2249 ****
  \file{.pyo} file.  Thus, the startup time of a script may be reduced
  by moving most of its code to a module and having a small bootstrap
! script that imports that module.
  
  \item
  It is possible to have a file called \file{spam.pyc} (or
! \file{spam.pyo} when \programopt{-O} is used) without a module
! \file{spam.py} in the same module.  This can be used to distribute
! a library of Python code in a form that is moderately hard to reverse
  engineer.
  
--- 2242,2253 ----
  \file{.pyo} file.  Thus, the startup time of a script may be reduced
  by moving most of its code to a module and having a small bootstrap
! script that imports that module.  It is also possible to name a
! \file{.pyc} or \file{.pyo} file directly on the command line.
  
  \item
  It is possible to have a file called \file{spam.pyc} (or
! \file{spam.pyo} when \programopt{-O} is used) without a file
! \file{spam.py} for the same module.  This can be used to distribute a
! library of Python code in a form that is moderately hard to reverse
  engineer.
  
***************
*** 2344,2347 ****
--- 2348,2352 ----
  \end{verbatim}
  
+ 
  \section{Packages \label{packages}}
  
***************
*** 2393,2396 ****
--- 2398,2402 ----
                ...
  \end{verbatim}
+ 
  The \file{__init__.py} files are required to make Python treat the
  directories as containing packages; this is done to prevent
***************
*** 2407,2410 ****
--- 2413,2417 ----
  import Sound.Effects.echo
  \end{verbatim}
+ 
  This loads the submodule \module{Sound.Effects.echo}.  It must be referenced
  with its full name, e.g.
***************
*** 2413,2416 ****
--- 2420,2424 ----
  Sound.Effects.echo.echofilter(input, output, delay=0.7, atten=4)
  \end{verbatim}
+ 
  An alternative way of importing the submodule is:
  
***************
*** 2418,2421 ****
--- 2426,2430 ----
  from Sound.Effects import echo
  \end{verbatim}
+ 
  This also loads the submodule \module{echo}, and makes it available without
  its package prefix, so it can be used as follows:
***************
*** 2501,2505 ****
  \end{verbatim}
  
- 
  In this example, the echo and surround modules are imported in the
  current namespace because they are defined in the
--- 2510,2513 ----
***************
*** 2665,2669 ****
  '3.14159265359'
  \end{verbatim}
! %
  Using the \code{\%} operator looks like this:
  
--- 2673,2677 ----
  '3.14159265359'
  \end{verbatim}
! 
  Using the \code{\%} operator looks like this:
  
***************
*** 3631,3635 ****
  \end{verbatim}
  
- 
  Methods may reference global names in the same way as ordinary
  functions.  The global scope associated with a method is the module
--- 3639,3642 ----
***************
*** 3791,3808 ****
  \end{verbatim}
  
- %\emph{Warning: this is an experimental feature.}  To avoid all
- %potential problems, refrain from using identifiers starting with
- %double underscore except for predefined uses like \samp{__init__}.  To
- %use private names while maintaining future compatibility: refrain from
- %using the same private name in classes related via subclassing; avoid
- %explicit (manual) mangling/unmangling; and assume that at some point
- %in the future, leading double underscore will revert to being just a
- %naming convention.  Discussion on extensive compile-time declarations
- %are currently underway, and it is impossible to predict what solution
- %will eventually be chosen for private names.  Double leading
- %underscore is still a candidate, of course --- just not the only one.
- %It is placed in the distribution in the belief that it is useful, and
- %so that widespread experience with its use can be gained.  It will not
- %be removed without providing a better solution and a migration path.
  
  \section{Odds and Ends \label{odds}}
--- 3798,3801 ----
***************
*** 3823,3827 ****
  john.salary = 1000
  \end{verbatim}
- 
  
  A piece of Python code that expects a particular abstract data type
--- 3816,3819 ----