--- rest25/tutorial/classes.rst	2008-12-19 16:58:06.000000000 +0900
+++ rest262/tutorial/classes.rst	2009-04-05 05:01:50.000000000 +0900
@@ -127,32 +127,33 @@
 function.  Outside functions, the local scope references the same namespace as
 the global scope: the module's namespace. Class definitions place yet another
 namespace in the local scope.
 
 It is important to realize that scopes are determined textually: the global
 scope of a function defined in a module is that module's namespace, no matter
 from where or by what alias the function is called.  On the other hand, the
 actual search for names is done dynamically, at run time --- however, the
 language definition is evolving towards static name resolution, at "compile"
 time, so don't rely on dynamic name resolution!  (In fact, local variables are
 already determined statically.)
 
-A special quirk of Python is that assignments always go into the innermost
-scope.  Assignments do not copy data --- they just bind names to objects.  The
-same is true for deletions: the statement ``del x`` removes the binding of ``x``
-from the namespace referenced by the local scope.  In fact, all operations that
-introduce new names use the local scope: in particular, import statements and
-function definitions bind the module or function name in the local scope.  (The
-:keyword:`global` statement can be used to indicate that particular variables
-live in the global scope.)
+A special quirk of Python is that -- if no :keyword:`global`
+statement is in effect -- assignments to names always go
+into the innermost scope.  Assignments do not copy data --- they just bind names
+to objects.  The same is true for deletions: the statement ``del x`` removes the
+binding of ``x`` from the namespace referenced by the local scope.  In fact, all
+operations that introduce new names use the local scope: in particular, import
+statements and function definitions bind the module or function name in the
+local scope.  (The :keyword:`global` statement can be used to indicate that
+particular variables live in the global scope.)
 
 
 .. _tut-firstclasses:
 
 A First Look at Classes
 =======================
 
 Classes introduce a little bit of new syntax, three new object types, and some
 new semantics.
 
 
 .. _tut-classdefinition:
@@ -198,25 +199,25 @@
 Class Objects
 -------------
 
 Class objects support two kinds of operations: attribute references and
 instantiation.
 
 *Attribute references* use the standard syntax used for all attribute references
 in Python: ``obj.name``.  Valid attribute names are all the names that were in
 the class's namespace when the class object was created.  So, if the class
 definition looked like this::
 
    class MyClass:
-       "A simple example class"
+       """A simple example class"""
        i = 12345
        def f(self):
            return 'hello world'
 
 then ``MyClass.i`` and ``MyClass.f`` are valid attribute references, returning
 an integer and a function object, respectively. Class attributes can also be
 assigned to, so you can change the value of ``MyClass.i`` by assignment.
 :attr:`__doc__` is also a valid attribute, returning the docstring belonging to
 the class: ``"A simple example class"``.
 
 Class *instantiation* uses function notation.  Just pretend that the class
 object is a parameterless function that returns a new instance of the class.
@@ -240,25 +241,25 @@
 in this example, a new, initialized instance can be obtained by::
 
    x = MyClass()
 
 Of course, the :meth:`__init__` method may have arguments for greater
 flexibility.  In that case, arguments given to the class instantiation operator
 are passed on to :meth:`__init__`.  For example, ::
 
    >>> class Complex:
    ...     def __init__(self, realpart, imagpart):
    ...         self.r = realpart
    ...         self.i = imagpart
-   ... 
+   ...
    >>> x = Complex(3.0, -4.5)
    >>> x.r, x.i
    (3.0, -4.5)
 
 
 .. _tut-instanceobjects:
 
 Instance Objects
 ----------------
 
 Now what can we do with instance objects?  The only operations understood by
 instance objects are attribute references.  There are two kinds of valid
@@ -332,25 +333,25 @@
 (pointers to) the instance object and the function object just found together in
 an abstract object: this is the method object.  When the method object is called
 with an argument list, it is unpacked again, a new argument list is constructed
 from the instance object and the original argument list, and the function object
 is called with this new argument list.
 
 
 .. _tut-remarks:
 
 Random Remarks
 ==============
 
-.. % [These should perhaps be placed more carefully...]
+.. These should perhaps be placed more carefully...
 
 Data attributes override method attributes with the same name; to avoid
 accidental name conflicts, which may cause hard-to-find bugs in large programs,
 it is wise to use some kind of convention that minimizes the chance of
 conflicts.  Possible conventions include capitalizing method names, prefixing
 data attribute names with a small unique string (perhaps just an underscore), or
 using verbs for methods and nouns for data attributes.
 
 Data attributes may be referenced by methods as well as by ordinary users
 ("clients") of an object.  In other words, classes are not usable to implement
 pure abstract data types.  In fact, nothing in Python makes it possible to
 enforce data hiding --- it is all based upon convention.  (On the other hand,
@@ -408,24 +409,27 @@
            self.add(x)
 
 Methods may reference global names in the same way as ordinary functions.  The
 global scope associated with a method is the module containing the class
 definition.  (The class itself is never used as a global scope!)  While one
 rarely encounters a good reason for using global data in a method, there are
 many legitimate uses of the global scope: for one thing, functions and modules
 imported into the global scope can be used by methods, as well as functions and
 classes defined in it.  Usually, the class containing the method is itself
 defined in this global scope, and in the next section we'll find some good
 reasons why a method would want to reference its own class!
 
+Each value is an object, and therefore has a *class* (also called its *type*).
+It is stored as ``object.__class__``.
+
 
 .. _tut-inheritance:
 
 Inheritance
 ===========
 
 Of course, a language feature would not be worthy of the name "class" without
 supporting inheritance.  The syntax for a derived class definition looks like
 this::
 
    class DerivedClassName(BaseClassName):
        <statement-1>
@@ -448,72 +452,93 @@
 applied recursively if the base class itself is derived from some other class.
 
 There's nothing special about instantiation of derived classes:
 ``DerivedClassName()`` creates a new instance of the class.  Method references
 are resolved as follows: the corresponding class attribute is searched,
 descending down the chain of base classes if necessary, and the method reference
 is valid if this yields a function object.
 
 Derived classes may override methods of their base classes.  Because methods
 have no special privileges when calling other methods of the same object, a
 method of a base class that calls another method defined in the same base class
 may end up calling a method of a derived class that overrides it.  (For C++
-programmers: all methods in Python are effectively :keyword:`virtual`.)
+programmers: all methods in Python are effectively ``virtual``.)
 
 An overriding method in a derived class may in fact want to extend rather than
 simply replace the base class method of the same name. There is a simple way to
 call the base class method directly: just call ``BaseClassName.methodname(self,
 arguments)``.  This is occasionally useful to clients as well.  (Note that this
 only works if the base class is defined or imported directly in the global
 scope.)
 
+Python has two builtin functions that work with inheritance:
+
+* Use :func:`isinstance` to check an object's type: ``isinstance(obj, int)``
+  will be ``True`` only if ``obj.__class__`` is :class:`int` or some class
+  derived from :class:`int`.
+
+* Use :func:`issubclass` to check class inheritance: ``issubclass(bool, int)``
+  is ``True`` since :class:`bool` is a subclass of :class:`int`.  However,
+  ``issubclass(unicode, str)`` is ``False`` since :class:`unicode` is not a
+  subclass of :class:`str` (they only share a common ancestor,
+  :class:`basestring`).
+
+
 
 .. _tut-multiple:
 
 Multiple Inheritance
 --------------------
 
 Python supports a limited form of multiple inheritance as well.  A class
 definition with multiple base classes looks like this::
 
    class DerivedClassName(Base1, Base2, Base3):
        <statement-1>
        .
        .
        .
        <statement-N>
 
-The only rule necessary to explain the semantics is the resolution rule used for
-class attribute references.  This is depth-first, left-to-right.  Thus, if an
+For old-style classes, the only rule is depth-first, left-to-right.  Thus, if an
 attribute is not found in :class:`DerivedClassName`, it is searched in
 :class:`Base1`, then (recursively) in the base classes of :class:`Base1`, and
 only if it is not found there, it is searched in :class:`Base2`, and so on.
 
 (To some people breadth first --- searching :class:`Base2` and :class:`Base3`
 before the base classes of :class:`Base1` --- looks more natural.  However, this
 would require you to know whether a particular attribute of :class:`Base1` is
 actually defined in :class:`Base1` or in one of its base classes before you can
 figure out the consequences of a name conflict with an attribute of
 :class:`Base2`.  The depth-first rule makes no differences between direct and
 inherited attributes of :class:`Base1`.)
 
-It is clear that indiscriminate use of multiple inheritance is a maintenance
-nightmare, given the reliance in Python on conventions to avoid accidental name
-conflicts.  A well-known problem with multiple inheritance is a class derived
-from two classes that happen to have a common base class.  While it is easy
-enough to figure out what happens in this case (the instance will have a single
-copy of "instance variables" or data attributes used by the common base class),
-it is not clear that these semantics are in any way useful.
-
-.. % % XXX Add rules for new-style MRO?
+For :term:`new-style class`\es, 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.
+
+With new-style classes, 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 can be accessed through multiple paths from the
+bottommost class).  For example, all new-style classes inherit from
+:class:`object`, so any case of multiple inheritance provides more than one path
+to reach :class:`object`.  To keep the base classes from being accessed more
+than once, the dynamic algorithm linearizes the search order in a way that
+preserves the left-to-right ordering specified in each class, that calls each
+parent only once, and that is monotonic (meaning that a class can be subclassed
+without affecting the precedence order of its parents).  Taken together, these
+properties make it possible to design reliable and extensible classes with
+multiple inheritance.  For more detail, see
+http://www.python.org/download/releases/2.3/mro/.
 
 
 .. _tut-private:
 
 Private Variables
 =================
 
 There is limited support for class-private identifiers.  Any identifier of the
 form ``__spam`` (at least two leading underscores, at most one trailing
 underscore) is textually replaced with ``_classname__spam``, where ``classname``
 is the current class name with leading underscore(s) stripped.  This mangling is
 done without regard to the syntactic position of the identifier, so it can be
@@ -557,30 +582,28 @@
 
    # Fill the fields of the record
    john.name = 'John Doe'
    john.dept = 'computer lab'
    john.salary = 1000
 
 A piece of Python code that expects a particular abstract data type can often be
 passed a class that emulates the methods of that data type instead.  For
 instance, if you have a function that formats some data from a file object, you
 can define a class with methods :meth:`read` and :meth:`readline` that get the
 data from a string buffer instead, and pass it as an argument.
 
-.. % (Unfortunately, this
-.. % technique has its limitations: a class can't define operations that
-.. % are accessed by special syntax such as sequence subscripting or
-.. % arithmetic operators, and assigning such a ``pseudo-file'' to
-.. % \code{sys.stdin} will not cause the interpreter to read further input
-.. % from it.)
+.. (Unfortunately, this technique has its limitations: a class can't define
+   operations that are accessed by special syntax such as sequence subscripting
+   or arithmetic operators, and assigning such a "pseudo-file" to sys.stdin will
+   not cause the interpreter to read further input from it.)
 
 Instance method objects have attributes, too: ``m.im_self`` is the instance
 object with the method :meth:`m`, and ``m.im_func`` is the function object
 corresponding to the method.
 
 
 .. _tut-exceptionclasses:
 
 Exceptions Are Classes Too
 ==========================
 
 User-defined exceptions are identified by classes as well.  Using this mechanism
@@ -694,42 +717,42 @@
    ...
    m
    a
    p
    s
 
 
 .. _tut-generators:
 
 Generators
 ==========
 
-Generators are a simple and powerful tool for creating iterators.  They are
-written like regular functions but use the :keyword:`yield` statement whenever
-they want to return data.  Each time :meth:`next` is called, the generator
-resumes where it left-off (it remembers all the data values and which statement
-was last executed).  An example shows that generators can be trivially easy to
-create::
+:term:`Generator`\s are a simple and powerful tool for creating iterators.  They
+are written like regular functions but use the :keyword:`yield` statement
+whenever they want to return data.  Each time :meth:`next` is called, the
+generator resumes where it left-off (it remembers all the data values and which
+statement was last executed).  An example shows that generators can be trivially
+easy to create::
 
    def reverse(data):
        for index in range(len(data)-1, -1, -1):
            yield data[index]
 
    >>> for char in reverse('golf'):
    ...     print char
    ...
    f
    l
    o
-   g	
+   g
 
 Anything that can be done with generators can also be done with class based
 iterators as described in the previous section.  What makes generators so
 compact is that the :meth:`__iter__` and :meth:`next` methods are created
 automatically.
 
 Another key feature is that the local variables and execution state are
 automatically saved between calls.  This made the function easier to write and
 much more clear than an approach using instance variables like ``self.index``
 and ``self.data``.
 
 In addition to automatic method creation and saving program state, when
