#1211, #1212, #1213: py3k fixes to the tutorial.

3 files changed, 42 insertions, 48 deletions

diff --git a/Doc/tutorial/classes.rst b/Doc/tutorial/classes.rst
index 696860d..8c45d1a 100644
--- a/Doc/tutorial/classes.rst
+++ b/Doc/tutorial/classes.rst
@@ -473,8 +473,8 @@ scope.)
 Multiple Inheritance
 --------------------
 
-Python supports a limited form of multiple inheritance as well.  A class
-definition with multiple base classes looks like this::
+Python supports a form of multiple inheritance as well.  A class definition with
+multiple base classes looks like this::
 
    class DerivedClassName(Base1, Base2, Base3):
        <statement-1>
@@ -483,15 +483,18 @@ definition with multiple base classes looks like this::
        .
        <statement-N>
 
-Formerly, the only rule was depth-first, left-to-right.  Thus, if an attribute
-was not found in :class:`DerivedClassName`, it was searched in :class:`Base1`,
-then (recursively) in the base classes of :class:`Base1`, and only if it was not
-found there, it was searched in :class:`Base2`, and so on.
-
-In the meantime, the method resolution order changes dynamically to support
-cooperative calls to :func:`super`.  This approach is known in some other
-multiple-inheritance languages as call-next-method and is more powerful than the
-super call found in single-inheritance languages.
+For most purposes, in the simplest cases, you can think of the search for
+attributes inherited from a parent class as depth-first, left-to-right, not
+searching twice in the same class where there is an overlap in the hierarchy.
+Thus, if an attribute is not found in :class:`DerivedClassName`, it is searched
+for in :class:`Base1`, then (recursively) in the base classes of :class:`Base1`,
+and if it was not found there, it was searched for in :class:`Base2`, and so on.
+
+In fact, it is slightly more complex than that; the method resolution order
+changes dynamically to support cooperative calls to :func:`super`.  This
+approach is known in some other multiple-inheritance languages as
+call-next-method and is more powerful than the super call found in
+single-inheritance languages.
 
 Dynamic ordering is necessary because all cases of multiple inheritance exhibit
 one or more diamond relationships (where one at least one of the parent classes
diff --git a/Doc/tutorial/interpreter.rst b/Doc/tutorial/interpreter.rst
index ce78399..5c67ba9 100644
--- a/Doc/tutorial/interpreter.rst
+++ b/Doc/tutorial/interpreter.rst
@@ -101,11 +101,14 @@ with the *secondary prompt*, by default three dots (``...``). The interpreter
 prints a welcome message stating its version number and a copyright notice
 before printing the first prompt::
 
-   python
-   Python 1.5.2b2 (#1, Feb 28 1999, 00:02:06)  [GCC 2.8.1] on sunos5
-   Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
+   $ python
+   Python 3.0a1 (py3k, Sep 12 2007, 12:21:02)
+   [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
+   Type "help", "copyright", "credits" or "license" for more information.
    >>>
 
+.. XXX update for final release of Python 3.0
+
 Continuation lines are needed when entering a multi-line construct. As an
 example, take a look at this :keyword:`if` statement::
 
@@ -170,44 +173,32 @@ The script can be given an executable mode, or permission, using the
 Source Code Encoding
 --------------------
 
-.. XXX out of date!
+By default, Python source files are treated as encoded in UTF-8.  In that
+encoding, characters of most languages in the world can be used simultaneously
+in string literals, identifiers and comments --- although the standard library
+only uses ASCII characters for identifiers, a convention that any portable code
+should follow.  To display all these characters properly, your editor must
+recognize that the file is UTF-8, and it must use a font that supports all the
+characters in the file.
 
-It is possible to use encodings different than ASCII in Python source files. The
-best way to do it is to put one more special comment line right after the ``#!``
-line to define the source file encoding::
+It is also possible to specify a different encoding for source files.  In order
+to do this, put one more special comment line right after the ``#!`` line to
+define the source file encoding::
 
    # -*- coding: encoding -*- 
 
+With that declaration, everything in the source file will be treated as having
+the encoding *encoding* instead of UTF-8.  The list of possible encodings can be
+found in the Python Library Reference, in the section on :mod:`codecs`.
 
-With that declaration, all characters in the source file will be treated as
-having the encoding *encoding*, and it will be possible to directly write
-Unicode string literals in the selected encoding.  The list of possible
-encodings can be found in the Python Library Reference, in the section on
-:mod:`codecs`.
-
-For example, to write Unicode literals including the Euro currency symbol, the
-ISO-8859-15 encoding can be used, with the Euro symbol having the ordinal value
-164.  This script will print the value 8364 (the Unicode codepoint corresponding
-to the Euro symbol) and then exit::
-
-   # -*- coding: iso-8859-15 -*-
-
-   currency = u"€"
-   print(ord(currency))
+For example, if your editor of choice does not support UTF-8 encoded files and
+insists on using some other encoding, say Windows-1252, you can write::
 
-If your editor supports saving files as ``UTF-8`` with a UTF-8 *byte order mark*
-(aka BOM), you can use that instead of an encoding declaration. IDLE supports
-this capability if ``Options/General/Default Source Encoding/UTF-8`` is set.
-Notice that this signature is not understood in older Python releases (2.2 and
-earlier), and also not understood by the operating system for script files with
-``#!`` lines (only used on Unix systems).
+   # -*- coding: cp-1252 -*-
 
-By using UTF-8 (either through the signature or an encoding declaration),
-characters of most languages in the world can be used simultaneously in string
-literals and comments.  Using non-ASCII characters in identifiers is not
-supported. To display all these characters properly, your editor must recognize
-that the file is UTF-8, and it must use a font that supports all the characters
-in the file.
+and still use all characters in the Windows-1252 character set in the source
+files.  The special encoding comment must be in the *first or second* line
+within the file.
 
 
 .. _tut-startup:
diff --git a/Doc/tutorial/introduction.rst b/Doc/tutorial/introduction.rst
index 1b24588..30adac9 100644
--- a/Doc/tutorial/introduction.rst
+++ b/Doc/tutorial/introduction.rst
@@ -131,9 +131,9 @@ and imaginary part.  To extract these parts from a complex number *z*, use
    0.5
 
 The conversion functions to floating point and integer (:func:`float`,
-:func:`int` and :func:`long`) don't work for complex numbers --- there is no one
-correct way to convert a complex number to a real number.  Use ``abs(z)`` to get
-its magnitude (as a float) or ``z.real`` to get its real part. ::
+:func:`int`) don't work for complex numbers --- there is not one correct way to
+convert a complex number to a real number.  Use ``abs(z)`` to get its magnitude
+(as a float) or ``z.real`` to get its real part::
 
    >>> a=3.0+4.0j
    >>> float(a)