--- rest25/whatsnew/2.0.rst	2008-12-19 16:58:06.000000000 +0900
+++ rest262/whatsnew/2.0.rst	2009-04-05 05:01:47.000000000 +0900
@@ -1,76 +1,76 @@
 ****************************
-  What's New in Python 2.0  
+  What's New in Python 2.0
 ****************************
 
 :Author: A.M. Kuchling and Moshe Zadka
 
 .. |release| replace:: 1.02
 
-.. % $Id: whatsnew20.tex 50964 2006-07-30 03:03:43Z fred.drake $
+.. $Id: whatsnew20.tex 50964 2006-07-30 03:03:43Z fred.drake $
 
 
 Introduction
 ============
 
 A new release of Python, version 2.0, was released on October 16, 2000. This
 article covers the exciting new features in 2.0, highlights some other useful
 changes, and points out a few incompatible changes that may require rewriting
 code.
 
 Python's development never completely stops between releases, and a steady flow
 of bug fixes and improvements are always being submitted. A host of minor fixes,
 a few optimizations, additional docstrings, and better error messages went into
 2.0; to list them all would be impossible, but they're certainly significant.
 Consult the publicly-available CVS logs if you want to see the full list.  This
 progress is due to the five developers working for  PythonLabs are now getting
 paid to spend their days fixing bugs, and also due to the improved communication
 resulting  from moving to SourceForge.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 What About Python 1.6?
 ======================
 
 Python 1.6 can be thought of as the Contractual Obligations Python release.
 After the core development team left CNRI in May 2000, CNRI requested that a 1.6
 release be created, containing all the work on Python that had been performed at
 CNRI.  Python 1.6 therefore represents the state of the CVS tree as of May 2000,
 with the most significant new feature being Unicode support.  Development
 continued after May, of course, so the 1.6 tree received a few fixes to ensure
 that it's forward-compatible with Python 2.0.  1.6 is therefore part of Python's
 evolution, and not a side branch.
 
 So, should you take much interest in Python 1.6?  Probably not.  The 1.6final
 and 2.0beta1 releases were made on the same day (September 5, 2000), the plan
 being to finalize Python 2.0 within a month or so.  If you have applications to
 maintain, there seems little point in breaking things by moving to 1.6, fixing
 them, and then having another round of breakage within a month by moving to 2.0;
 you're better off just going straight to 2.0.  Most of the really interesting
 features described in this document are only in 2.0, because a lot of work was
 done between May and September.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 New Development Process
 =======================
 
 The most important change in Python 2.0 may not be to the code at all, but to
 how Python is developed: in May 2000 the Python developers began using the tools
 made available by SourceForge for storing  source code, tracking bug reports,
 and managing the queue of patch submissions.  To report bugs or submit patches
 for Python 2.0, use the bug tracking and patch manager tools available from
-Python's project page, located at `<http://sourceforge.net/projects/python/>`_.
+Python's project page, located at http://sourceforge.net/projects/python/.
 
 The most important of the services now hosted at SourceForge is the Python CVS
 tree, the version-controlled repository containing the source code for Python.
 Previously, there were roughly 7 or so people who had write access to the CVS
 tree, and all patches had to be inspected and checked in by one of the people on
 this short list. Obviously, this wasn't very scalable.  By moving the CVS tree
 to SourceForge, it became possible to grant write access to more people; as of
 September 2000 there were 27 people able to check in changes, a fourfold
 increase.  This makes possible large-scale changes that wouldn't be attempted if
 they'd have to be filtered through the small group of core developers.  For
 example, one day Peter Schneider-Kamp took it into his head to drop K&R C
 compatibility and convert the C source for Python to ANSI C. After getting
@@ -121,29 +121,29 @@
    providing information to the Python community, or describing a new feature for
    Python.  The PEP should provide a concise technical specification of the feature
    and a rationale for the feature.
 
    We intend PEPs to be the primary mechanisms for proposing new features, for
    collecting community input on an issue, and for documenting the design decisions
    that have gone into Python.  The PEP author is responsible for building
    consensus within the community and documenting dissenting opinions.
 
 Read the rest of PEP 1 for the details of the PEP editorial process, style, and
 format.  PEPs are kept in the Python CVS tree on SourceForge, though they're not
 part of the Python 2.0 distribution, and are also available in HTML form from
-`<http://www.python.org/peps/>`_.  As of September 2000, there are 25 PEPS,
-ranging from PEP 201, "Lockstep Iteration", to PEP 225, "Elementwise/Objectwise
+http://www.python.org/peps/.  As of September 2000, there are 25 PEPS, ranging
+from PEP 201, "Lockstep Iteration", to PEP 225, "Elementwise/Objectwise
 Operators".
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Unicode
 =======
 
 The largest new feature in Python 2.0 is a new fundamental data type: Unicode
 strings.  Unicode uses 16-bit numbers to represent characters instead of the
 8-bit number used by ASCII, meaning that 65,536 distinct characters can be
 supported.
 
 The final interface for Unicode support was arrived at through countless often-
 stormy discussions on the python-dev mailing list, and mostly implemented by
@@ -151,46 +151,46 @@
 Lundh.  A detailed explanation of the interface was written up as :pep:`100`,
 "Python Unicode Integration". This article will simply cover the most
 significant points about the Unicode interfaces.
 
 In Python source code, Unicode strings are written as ``u"string"``.  Arbitrary
 Unicode characters can be written using a new escape sequence, ``\uHHHH``, where
 *HHHH* is a 4-digit hexadecimal number from 0000 to FFFF.  The existing
 ``\xHHHH`` escape sequence can also be used, and octal escapes can be used for
 characters up to U+01FF, which is represented by ``\777``.
 
 Unicode strings, just like regular strings, are an immutable sequence type.
 They can be indexed and sliced, but not modified in place. Unicode strings have
-an :meth:`encode( [encoding] )` method that returns an 8-bit string in the
-desired encoding.  Encodings are named by strings, such as ``'ascii'``,
-``'utf-8'``, ``'iso-8859-1'``, or whatever.  A codec API is defined for
-implementing and registering new encodings that are then available throughout a
-Python program.  If an encoding isn't specified, the default encoding is usually
-7-bit ASCII, though it can be changed for your Python installation by calling
-the :func:`sys.setdefaultencoding(encoding)` function in a customised version of
+an ``encode( [encoding] )`` method that returns an 8-bit string in the desired
+encoding.  Encodings are named by strings, such as ``'ascii'``, ``'utf-8'``,
+``'iso-8859-1'``, or whatever.  A codec API is defined for implementing and
+registering new encodings that are then available throughout a Python program.
+If an encoding isn't specified, the default encoding is usually 7-bit ASCII,
+though it can be changed for your Python installation by calling the
+:func:`sys.setdefaultencoding(encoding)` function in a customised version of
 :file:`site.py`.
 
 Combining 8-bit and Unicode strings always coerces to Unicode, using the default
 ASCII encoding; the result of ``'a' + u'bc'`` is ``u'abc'``.
 
 New built-in functions have been added, and existing built-ins modified to
 support Unicode:
 
 * ``unichr(ch)`` returns a Unicode string 1 character long, containing the
   character *ch*.
 
 * ``ord(u)``, where *u* is a 1-character regular or Unicode string, returns the
   number of the character as an integer.
 
-* ``unicode(string [, *encoding*]  [, *errors*] )`` creates a Unicode string
+* ``unicode(string [, encoding]  [, errors] )`` creates a Unicode string
   from an 8-bit string.  ``encoding`` is a string naming the encoding to use. The
   ``errors`` parameter specifies the treatment of characters that are invalid for
   the current encoding; passing ``'strict'`` as the value causes an exception to
   be raised on any encoding error, while ``'ignore'`` causes errors to be silently
   ignored and ``'replace'`` uses U+FFFD, the official replacement character, in
   case of any problems.
 
 * The :keyword:`exec` statement, and various built-ins such as ``eval()``,
   ``getattr()``, and ``setattr()`` will also accept Unicode strings as well as
   regular strings.  (It's possible that the process of fixing this missed some
   built-ins; if you find a built-in function that accepts strings but doesn't
   accept Unicode strings at all, please report it as a bug.)
@@ -246,153 +246,153 @@
    print repr(input.read())
    input.close()
 
 Unicode-aware regular expressions are available through the :mod:`re` module,
 which has a new underlying implementation called SRE written by Fredrik Lundh of
 Secret Labs AB.
 
 A ``-U`` command line option was added which causes the Python compiler to
 interpret all string literals as Unicode string literals. This is intended to be
 used in testing and future-proofing your Python code, since some future version
 of Python may drop support for 8-bit strings and provide only Unicode strings.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 List Comprehensions
 ===================
 
 Lists are a workhorse data type in Python, and many programs manipulate a list
 at some point.  Two common operations on lists are to loop over them, and either
 pick out the elements that meet a certain criterion, or apply some function to
 each element.  For example, given a list of strings, you might want to pull out
 all the strings containing a given substring, or strip off trailing whitespace
 from each line.
 
 The existing :func:`map` and :func:`filter` functions can be used for this
 purpose, but they require a function as one of their arguments.  This is fine if
 there's an existing built-in function that can be passed directly, but if there
 isn't, you have to create a little function to do the required work, and
 Python's scoping rules make the result ugly if the little function needs
 additional information.  Take the first example in the previous paragraph,
 finding all the strings in the list containing a given substring.  You could
 write the following to do it::
 
-   # Given the list L, make a list of all strings 
+   # Given the list L, make a list of all strings
    # containing the substring S.
-   sublist = filter( lambda s, substring=S: 
+   sublist = filter( lambda s, substring=S:
                         string.find(s, substring) != -1,
-   	          L)
+                     L)
 
 Because of Python's scoping rules, a default argument is used so that the
 anonymous function created by the :keyword:`lambda` statement knows what
 substring is being searched for.  List comprehensions make this cleaner::
 
    sublist = [ s for s in L if string.find(s, S) != -1 ]
 
 List comprehensions have the form::
 
-   [ expression for expr in sequence1 
+   [ expression for expr in sequence1
                 for expr2 in sequence2 ...
-   	     for exprN in sequenceN
+                for exprN in sequenceN
                 if condition ]
 
 The :keyword:`for`...\ :keyword:`in` clauses contain the sequences to be
 iterated over.  The sequences do not have to be the same length, because they
 are *not* iterated over in parallel, but from left to right; this is explained
 more clearly in the following paragraphs.  The elements of the generated list
 will be the successive values of *expression*.  The final :keyword:`if` clause
 is optional; if present, *expression* is only evaluated and added to the result
 if *condition* is true.
 
 To make the semantics very clear, a list comprehension is equivalent to the
 following Python code::
 
    for expr1 in sequence1:
        for expr2 in sequence2:
        ...
            for exprN in sequenceN:
                 if (condition):
-                     # Append the value of 
-                     # the expression to the 
+                     # Append the value of
+                     # the expression to the
                      # resulting list.
 
 This means that when there are multiple :keyword:`for`...\ :keyword:`in`
 clauses, the resulting list will be equal to the product of the lengths of all
 the sequences.  If you have two lists of length 3, the output list is 9 elements
 long::
 
    seq1 = 'abc'
    seq2 = (1,2,3)
    >>> [ (x,y) for x in seq1 for y in seq2]
    [('a', 1), ('a', 2), ('a', 3), ('b', 1), ('b', 2), ('b', 3), ('c', 1),
    ('c', 2), ('c', 3)]
 
 To avoid introducing an ambiguity into Python's grammar, if *expression* is
 creating a tuple, it must be surrounded with parentheses.  The first list
 comprehension below is a syntax error, while the second one is correct::
 
    # Syntax error
    [ x,y for x in seq1 for y in seq2]
    # Correct
    [ (x,y) for x in seq1 for y in seq2]
 
 The idea of list comprehensions originally comes from the functional programming
-language Haskell (`<http://www.haskell.org>`_).  Greg Ewing argued most
-effectively for adding them to Python and wrote the initial list comprehension
-patch, which was then discussed for a seemingly endless time on the python-dev
-mailing list and kept up-to-date by Skip Montanaro.
+language Haskell (http://www.haskell.org).  Greg Ewing argued most effectively
+for adding them to Python and wrote the initial list comprehension patch, which
+was then discussed for a seemingly endless time on the python-dev mailing list
+and kept up-to-date by Skip Montanaro.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Augmented Assignment
 ====================
 
 Augmented assignment operators, another long-requested feature, have been added
 to Python 2.0.  Augmented assignment operators include ``+=``, ``-=``, ``*=``,
 and so forth.  For example, the statement ``a += 2`` increments the value of the
 variable  ``a`` by 2, equivalent to the slightly lengthier ``a = a + 2``.
 
 The full list of supported assignment operators is ``+=``, ``-=``, ``*=``,
 ``/=``, ``%=``, ``**=``, ``&=``, ``|=``, ``^=``, ``>>=``, and ``<<=``.  Python
 classes can override the augmented assignment operators by defining methods
 named :meth:`__iadd__`, :meth:`__isub__`, etc.  For example, the following
 :class:`Number` class stores a number and supports using += to create a new
 instance with an incremented value.
 
-.. % The empty groups below prevent conversion to guillemets.
+.. The empty groups below prevent conversion to guillemets.
 
 ::
 
    class Number:
        def __init__(self, value):
            self.value = value
        def __iadd__(self, increment):
-   	return Number( self.value + increment)
+           return Number( self.value + increment)
 
    n = Number(5)
    n += 3
    print n.value
 
 The :meth:`__iadd__` special method is called with the value of the increment,
 and should return a new instance with an appropriately modified value; this
 return value is bound as the new value of the variable on the left-hand side.
 
 Augmented assignment operators were first introduced in the C programming
 language, and most C-derived languages, such as :program:`awk`, C++, Java, Perl,
 and PHP also support them.  The augmented assignment patch was implemented by
 Thomas Wouters.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 String Methods
 ==============
 
 Until now string-manipulation functionality was in the :mod:`string` module,
 which was usually a front-end for the :mod:`strop` module written in C.  The
 addition of Unicode posed a difficulty for the :mod:`strop` module, because the
 functions would all need to be rewritten in order to accept either 8-bit or
 Unicode strings.  For functions such as :func:`string.replace`, which takes 3
 string arguments, that means eight possible permutations, and correspondingly
 complicated code.
@@ -417,25 +417,25 @@
 
 Two methods which have no parallel in pre-2.0 versions, although they did exist
 in JPython for quite some time, are :meth:`startswith` and :meth:`endswith`.
 ``s.startswith(t)`` is equivalent to ``s[:len(t)] == t``, while
 ``s.endswith(t)`` is equivalent to ``s[-len(t):] == t``.
 
 One other method which deserves special mention is :meth:`join`.  The
 :meth:`join` method of a string receives one parameter, a sequence of strings,
 and is equivalent to the :func:`string.join` function from the old :mod:`string`
 module, with the arguments reversed. In other words, ``s.join(seq)`` is
 equivalent to the old ``string.join(seq, s)``.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Garbage Collection of Cycles
 ============================
 
 The C implementation of Python uses reference counting to implement garbage
 collection.  Every Python object maintains a count of the number of references
 pointing to itself, and adjusts the count as references are created or
 destroyed.  Once the reference count reaches zero, the object is no longer
 accessible, since you need to have a reference to an object to access it, and if
 the count is zero, no references exist any longer.
 
@@ -479,25 +479,25 @@
 :option:`--without-cycle-gc` switch when running the :program:`configure`
 script.
 
 Several people tackled this problem and contributed to a solution.  An early
 implementation of the cycle detection approach was written by Toby Kelsey.  The
 current algorithm was suggested by Eric Tiedemann during a visit to CNRI, and
 Guido van Rossum and Neil Schemenauer wrote two different implementations, which
 were later integrated by Neil.  Lots of other people offered suggestions along
 the way; the March 2000 archives of the python-dev mailing list contain most of
 the relevant discussion, especially in the threads titled "Reference cycle
 collection for Python" and "Finalization again".
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Other Core Changes
 ==================
 
 Various minor changes have been made to Python's syntax and built-in functions.
 None of the changes are very far-reaching, but they're handy conveniences.
 
 
 Minor Language Changes
 ----------------------
 
@@ -556,50 +556,50 @@
    a.append(a)
    b.append(b)
 
 The comparison ``a==b`` returns true, because the two recursive data structures
 are isomorphic. See the thread "trashcan and PR#7" in the April 2000 archives of
 the python-dev mailing list for the discussion leading up to this
 implementation, and some useful relevant links.    Note that comparisons can now
 also raise exceptions. In earlier versions of Python, a comparison operation
 such as ``cmp(a,b)`` would always produce an answer, even if a user-defined
 :meth:`__cmp__` method encountered an error, since the resulting exception would
 simply be silently swallowed.
 
-.. % Starting URL:
-.. % http://www.python.org/pipermail/python-dev/2000-April/004834.html
+.. Starting URL:
+.. http://www.python.org/pipermail/python-dev/2000-April/004834.html
 
 Work has been done on porting Python to 64-bit Windows on the Itanium processor,
 mostly by Trent Mick of ActiveState.  (Confusingly, ``sys.platform`` is still
 ``'win32'`` on Win64 because it seems that for ease of porting, MS Visual C++
 treats code as 32 bit on Itanium.) PythonWin also supports Windows CE; see the
-Python CE page at `<http://starship.python.net/crew/mhammond/ce/>`_ for more
+Python CE page at http://starship.python.net/crew/mhammond/ce/ for more
 information.
 
 Another new platform is Darwin/MacOS X; initial support for it is in Python 2.0.
 Dynamic loading works, if you specify "configure --with-dyld --with-suffix=.x".
 Consult the README in the Python source distribution for more instructions.
 
 An attempt has been made to alleviate one of Python's warts, the often-confusing
 :exc:`NameError` exception when code refers to a local variable before the
 variable has been assigned a value.  For example, the following code raises an
 exception on the :keyword:`print` statement in both 1.5.2 and 2.0; in 1.5.2 a
 :exc:`NameError` exception is raised, while 2.0 raises a new
 :exc:`UnboundLocalError` exception. :exc:`UnboundLocalError` is a subclass of
 :exc:`NameError`, so any existing code that expects :exc:`NameError` to be
 raised should still work. ::
 
    def f():
        print "i=",i
-       i = i + 1 
+       i = i + 1
    f()
 
 Two new exceptions, :exc:`TabError` and :exc:`IndentationError`, have been
 introduced.  They're both subclasses of :exc:`SyntaxError`, and are raised when
 Python code is found to be improperly indented.
 
 
 Changes to Built-in Functions
 -----------------------------
 
 A new built-in, :func:`zip(seq1, seq2, ...)`, has been added.  :func:`zip`
 returns a list of tuples where each tuple contains the i-th element from each of
@@ -618,39 +618,39 @@
 :mod:`sys` module.  ``sys.version_info`` is a tuple ``(major, minor, micro,
 level, serial)`` For example, in a hypothetical 2.0.1beta1, ``sys.version_info``
 would be ``(2, 0, 1, 'beta', 1)``. *level* is a string such as ``"alpha"``,
 ``"beta"``, or ``"final"`` for a final release.
 
 Dictionaries have an odd new method, :meth:`setdefault(key, default)`, which
 behaves similarly to the existing :meth:`get` method.  However, if the key is
 missing, :meth:`setdefault` both returns the value of *default* as :meth:`get`
 would do, and also inserts it into the dictionary as the value for *key*.  Thus,
 the following lines of code::
 
    if dict.has_key( key ): return dict[key]
-   else: 
+   else:
        dict[key] = []
        return dict[key]
 
 can be reduced to a single ``return dict.setdefault(key, [])`` statement.
 
 The interpreter sets a maximum recursion depth in order to catch runaway
 recursion before filling the C stack and causing a core dump or GPF..
 Previously this limit was fixed when you compiled Python, but in 2.0 the maximum
 recursion depth can be read and modified using :func:`sys.getrecursionlimit` and
 :func:`sys.setrecursionlimit`. The default value is 1000, and a rough maximum
 value for a given platform can be found by running a new script,
 :file:`Misc/find_recursionlimit.py`.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Porting to 2.0
 ==============
 
 New Python releases try hard to be compatible with previous releases, and the
 record has been pretty good.  However, some changes are considered useful
 enough, usually because they fix initial design decisions that turned out to be
 actively mistaken, that breaking backward compatibility can't always be avoided.
 This section lists the changes in Python 2.0 that may cause old Python code to
 break.
 
@@ -719,31 +719,31 @@
 :func:`sprintf`, while :func:`str` uses ``%.12g`` as before.  The effect is that
 :func:`repr` may occasionally show more decimal places than  :func:`str`, for
 certain numbers.  For example, the number 8.1 can't be represented exactly in
 binary, so ``repr(8.1)`` is ``'8.0999999999999996'``, while str(8.1) is
 ``'8.1'``.
 
 The ``-X`` command-line option, which turned all standard exceptions into
 strings instead of classes, has been removed; the standard exceptions will now
 always be classes.  The :mod:`exceptions` module containing the standard
 exceptions was translated from Python to a built-in C module, written by Barry
 Warsaw and Fredrik Lundh.
 
-.. % Commented out for now -- I don't think anyone will care.
-.. % The pattern and match objects provided by SRE are C types, not Python
-.. % class instances as in 1.5.  This means you can no longer inherit from
-.. % \class{RegexObject} or \class{MatchObject}, but that shouldn't be much
-.. % of a problem since no one should have been doing that in the first
-.. % place.
-.. % ======================================================================
+.. Commented out for now -- I don't think anyone will care.
+   The pattern and match objects provided by SRE are C types, not Python
+   class instances as in 1.5.  This means you can no longer inherit from
+   \class{RegexObject} or \class{MatchObject}, but that shouldn't be much
+   of a problem since no one should have been doing that in the first
+   place.
+.. ======================================================================
 
 
 Extending/Embedding Changes
 ===========================
 
 Some of the changes are under the covers, and will only be apparent to people
 writing C extension modules or embedding a Python interpreter in a larger
 application.  If you aren't dealing with Python's C API, you can safely skip
 this section.
 
 The version number of the Python C API was incremented, so C extensions compiled
 for 1.5.2 must be recompiled in order to work with 2.0.  On Windows, it's not
@@ -796,25 +796,25 @@
 
 Three new convenience functions intended for adding constants to a module's
 dictionary at module initialization time were added: :func:`PyModule_AddObject`,
 :func:`PyModule_AddIntConstant`, and :func:`PyModule_AddStringConstant`.  Each
 of these functions takes a module object, a null-terminated C string containing
 the name to be added, and a third argument for the value to be assigned to the
 name.  This third argument is, respectively, a Python object, a C long, or a C
 string.
 
 A wrapper API was added for Unix-style signal handlers. :func:`PyOS_getsig` gets
 a signal handler and :func:`PyOS_setsig` will set a new handler.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Distutils: Making Modules Easy to Install
 =========================================
 
 Before Python 2.0, installing modules was a tedious affair -- there was no way
 to figure out automatically where Python is installed, or what compiler options
 to use for extension modules.  Software authors had to go through an arduous
 ritual of editing Makefiles and configuration files, which only really work on
 Unix and leave Windows and MacOS unsupported.  Python users faced wildly
 differing installation instructions which varied between different extension
 packages, which made administering a Python installation something of  a chore.
@@ -827,64 +827,63 @@
 setup.py install``".  The platform will be automatically detected, the compiler
 will be recognized, C extension modules will be compiled, and the distribution
 installed into the proper directory.  Optional command-line arguments provide
 more control over the installation process, the distutils package offers many
 places to override defaults -- separating the build from the install, building
 or installing in non-default directories, and more.
 
 In order to use the Distutils, you need to write a :file:`setup.py` script.  For
 the simple case, when the software contains only .py files, a minimal
 :file:`setup.py` can be just a few lines long::
 
    from distutils.core import setup
-   setup (name = "foo", version = "1.0", 
+   setup (name = "foo", version = "1.0",
           py_modules = ["module1", "module2"])
 
 The :file:`setup.py` file isn't much more complicated if the software consists
 of a few packages::
 
    from distutils.core import setup
-   setup (name = "foo", version = "1.0", 
+   setup (name = "foo", version = "1.0",
           packages = ["package", "package.subpackage"])
 
 A C extension can be the most complicated case; here's an example taken from
 the PyXML package::
 
    from distutils.core import setup, Extension
 
    expat_extension = Extension('xml.parsers.pyexpat',
-   	define_macros = [('XML_NS', None)],
-   	include_dirs = [ 'extensions/expat/xmltok',
-   	                 'extensions/expat/xmlparse' ],
-   	sources = [ 'extensions/pyexpat.c',
-   	            'extensions/expat/xmltok/xmltok.c',
-    		    'extensions/expat/xmltok/xmlrole.c',
-                     ]
+        define_macros = [('XML_NS', None)],
+        include_dirs = [ 'extensions/expat/xmltok',
+                         'extensions/expat/xmlparse' ],
+        sources = [ 'extensions/pyexpat.c',
+                    'extensions/expat/xmltok/xmltok.c',
+                    'extensions/expat/xmltok/xmlrole.c', ]
           )
-   setup (name = "PyXML", version = "0.5.4", 
+   setup (name = "PyXML", version = "0.5.4",
           ext_modules =[ expat_extension ] )
 
 The Distutils can also take care of creating source and binary distributions.
 The "sdist" command, run by "``python setup.py sdist``', builds a source
 distribution such as :file:`foo-1.0.tar.gz`. Adding new commands isn't
 difficult, "bdist_rpm" and "bdist_wininst" commands have already been
 contributed to create an RPM distribution and a Windows installer for the
 software, respectively.  Commands to create other distribution formats such as
 Debian packages and Solaris :file:`.pkg` files are in various stages of
 development.
 
 All this is documented in a new manual, *Distributing Python Modules*, that
 joins the basic set of Python documentation.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 XML Modules
 ===========
 
 Python 1.5.2 included a simple XML parser in the form of the :mod:`xmllib`
 module, contributed by Sjoerd Mullender.  Since 1.5.2's release, two different
 interfaces for processing XML have become common: SAX2 (version 2 of the Simple
 API for XML) provides an event-driven interface with some similarities to
 :mod:`xmllib`, and the DOM (Document Object Model) provides a tree-based
 interface, transforming an XML document into a tree of nodes that can be
 traversed and modified.  Python 2.0 includes a SAX2 interface and a stripped-
@@ -926,25 +925,25 @@
 
    # Create a parser object
    parser = sax.make_parser()
 
    # Tell it what handler to use
    handler = SimpleHandler()
    parser.setContentHandler( handler )
 
    # Parse a file!
    parser.parse( 'hamlet.xml' )
 
 For more information, consult the Python documentation, or the XML HOWTO at
-`<http://pyxml.sourceforge.net/topics/howto/xml-howto.html>`_.
+http://pyxml.sourceforge.net/topics/howto/xml-howto.html.
 
 
 DOM Support
 -----------
 
 The Document Object Model is a tree-based representation for an XML document.  A
 top-level :class:`Document` instance is the root of the tree, and has a single
 child which is the top-level :class:`Element` instance. This :class:`Element`
 has children nodes representing character data and any sub-elements, which may
 have further children of their own, and so forth.  Using the DOM you can
 traverse the resulting tree any way you like, access element and attribute
 values, insert and delete nodes, and convert the tree back into XML.
@@ -996,45 +995,44 @@
    # the third child) before the 20th child.
    root.insertBefore( root.childNodes[0], root.childNodes[20] )
 
 Again, I will refer you to the Python documentation for a complete listing of
 the different :class:`Node` classes and their various methods.
 
 
 Relationship to PyXML
 ---------------------
 
 The XML Special Interest Group has been working on XML-related Python code for a
 while.  Its code distribution, called PyXML, is available from the SIG's Web
-pages at `<http://www.python.org/sigs/xml-sig/>`_. The PyXML distribution also
-used the package name ``xml``.  If you've written programs that used PyXML,
-you're probably wondering about its compatibility with the 2.0 :mod:`xml`
-package.
+pages at http://www.python.org/sigs/xml-sig/. The PyXML distribution also used
+the package name ``xml``.  If you've written programs that used PyXML, you're
+probably wondering about its compatibility with the 2.0 :mod:`xml` package.
 
 The answer is that Python 2.0's :mod:`xml` package isn't compatible with PyXML,
 but can be made compatible by installing a recent version PyXML.  Many
 applications can get by with the XML support that is included with Python 2.0,
 but more complicated applications will require that the full PyXML package will
 be installed.  When installed, PyXML versions 0.6.0 or greater will replace the
 :mod:`xml` package shipped with Python, and will be a strict superset of the
 standard package, adding a bunch of additional features.  Some of the additional
 features in PyXML include:
 
 * 4DOM, a full DOM implementation from FourThought, Inc.
 
 * The xmlproc validating parser, written by Lars Marius Garshol.
 
 * The :mod:`sgmlop` parser accelerator module, written by Fredrik Lundh.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Module changes
 ==============
 
 Lots of improvements and bugfixes were made to Python's extensive standard
 library; some of the affected modules include :mod:`readline`,
 :mod:`ConfigParser`, :mod:`cgi`, :mod:`calendar`, :mod:`posix`, :mod:`readline`,
 :mod:`xmllib`, :mod:`aifc`, :mod:`chunk, wave`, :mod:`random`, :mod:`shelve`,
 and :mod:`nntplib`.  Consult the CVS logs for the exact patch-by-patch details.
 
 Brian Gallew contributed OpenSSL support for the :mod:`socket` module.  OpenSSL
@@ -1061,25 +1059,25 @@
 Andrich's enhanced version, to provide many additional functions from ncurses
 and SYSV curses, such as colour, alternative character set support, pads, and
 mouse support.  This means the module is no longer compatible with operating
 systems that only have BSD curses, but there don't seem to be any currently
 maintained OSes that fall into this category.
 
 As mentioned in the earlier discussion of 2.0's Unicode support, the underlying
 implementation of the regular expressions provided by the :mod:`re` module has
 been changed.  SRE, a new regular expression engine written by Fredrik Lundh and
 partially funded by Hewlett Packard, supports matching against both 8-bit
 strings and Unicode strings.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 New modules
 ===========
 
 A number of new modules were added.  We'll simply list them with brief
 descriptions; consult the 2.0 documentation for the details of a particular
 module.
 
 * :mod:`atexit`:  For registering functions to be called before the Python
   interpreter exits. Code that currently sets ``sys.exitfunc`` directly should be
   changed to  use the :mod:`atexit` module instead, importing :mod:`atexit` and
@@ -1137,25 +1135,25 @@
   been added to the core  distribution, and enhanced to support Unicode.
   :mod:`_winreg` was written by Bill Tutt and Mark Hammond.
 
 * :mod:`zipfile`: A module for reading and writing ZIP-format archives.  These
   are archives produced by :program:`PKZIP` on DOS/Windows or :program:`zip` on
   Unix, not to be confused with :program:`gzip`\ -format files (which are
   supported by the :mod:`gzip` module) (Contributed by James C. Ahlstrom.)
 
 * :mod:`imputil`: A module that provides a simpler way for writing customised
   import hooks, in comparison to the existing :mod:`ihooks` module.  (Implemented
   by Greg Stein, with much discussion on python-dev along the way.)
 
-.. % ======================================================================
+.. ======================================================================
 
 
 IDLE Improvements
 =================
 
 IDLE is the official Python cross-platform IDE, written using Tkinter. Python
 2.0 includes IDLE 0.6, which adds a number of new features and improvements.  A
 partial list:
 
 * UI improvements and optimizations, especially in the area of syntax
   highlighting and auto-indentation.
 
@@ -1171,25 +1169,25 @@
 * IDLE now has a command line, which is largely similar to  the vanilla Python
   interpreter.
 
 * Call tips were added in many places.
 
 * IDLE can now be installed as a package.
 
 * In the editor window, there is now a line/column bar at the bottom.
 
 * Three new keystroke commands: Check module (Alt-F5), Import module (F5) and
   Run script (Ctrl-F5).
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Deleted and Deprecated Modules
 ==============================
 
 A few modules have been dropped because they're obsolete, or because there are
 now better ways to do the same thing.  The :mod:`stdwin` module is gone; it was
 for a platform-independent windowing toolkit that's no longer developed.
 
 A number of modules have been moved to the :file:`lib-old` subdirectory:
 :mod:`cmp`, :mod:`cmpcache`, :mod:`dircmp`, :mod:`dump`,  :mod:`find`,
 :mod:`grep`, :mod:`packmail`,  :mod:`poly`, :mod:`util`, :mod:`whatsound`,
