summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorGeorg Brandl <georg@python.org>2007-09-28 13:13:35 (GMT)
committerGeorg Brandl <georg@python.org>2007-09-28 13:13:35 (GMT)
commit2d2590de49081eea38152e0a25496069a059c69e (patch)
treeb80eb1ae3784fd11b7edfbd64092824483838ef3
parent7c77f753b452cfd423c2cb790977ddcfdabfa162 (diff)
downloadcpython-2d2590de49081eea38152e0a25496069a059c69e.zip
cpython-2d2590de49081eea38152e0a25496069a059c69e.tar.gz
cpython-2d2590de49081eea38152e0a25496069a059c69e.tar.bz2
#1211, #1212, #1213: py3k fixes to the tutorial.
-rw-r--r--Doc/ACKS.txt1
-rw-r--r--Doc/tutorial/classes.rst25
-rw-r--r--Doc/tutorial/interpreter.rst59
-rw-r--r--Doc/tutorial/introduction.rst6
4 files changed, 43 insertions, 48 deletions
diff --git a/Doc/ACKS.txt b/Doc/ACKS.txt
index f695403..0b107c8 100644
--- a/Doc/ACKS.txt
+++ b/Doc/ACKS.txt
@@ -65,6 +65,7 @@ docs@python.org), and we'll be glad to correct the problem.
* Harald Hanche-Olsen
* Manus Hand
* Gerhard Häring
+* Peter Harris
* Travis B. Hartwell
* Tim Hatch
* Janko Hauser
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)