--- rest25/whatsnew/2.3.rst	2008-12-19 16:58:06.000000000 +0900
+++ rest262/whatsnew/2.3.rst	2009-04-05 05:01:47.000000000 +0900
@@ -1,50 +1,49 @@
 ****************************
-  What's New in Python 2.3  
+  What's New in Python 2.3
 ****************************
 
 :Author: A.M. Kuchling
 
 .. |release| replace:: 1.01
 
-.. % $Id: whatsnew23.tex 50964 2006-07-30 03:03:43Z fred.drake $
+.. $Id: whatsnew23.tex 54631 2007-03-31 11:58:36Z georg.brandl $
 
 This article explains the new features in Python 2.3.  Python 2.3 was released
 on July 29, 2003.
 
 The main themes for Python 2.3 are polishing some of the features added in 2.2,
 adding various small but useful enhancements to the core language, and expanding
 the standard library.  The new object model introduced in the previous version
 has benefited from 18 months of bugfixes and from optimization efforts that have
 improved the performance of new-style classes.  A few new built-in functions
 have been added such as :func:`sum` and :func:`enumerate`.  The :keyword:`in`
 operator can now be used for substring searches (e.g. ``"ab" in "abc"`` returns
 :const:`True`).
 
 Some of the many new library features include Boolean, set, heap, and date/time
 data types, the ability to import modules from ZIP-format archives, metadata
 support for the long-awaited Python catalog, an updated version of IDLE, and
 modules for logging messages, wrapping text, parsing CSV files, processing
 command-line options, using BerkeleyDB databases...  the list of new and
 enhanced modules is lengthy.
 
 This article doesn't attempt to provide a complete specification of the new
 features, but instead provides a convenient overview.  For full details, you
 should refer to the documentation for Python 2.3, such as the Python Library
-Reference (XXX reference: ../lib/lib.html) and the Python Reference Manual (XXX
-reference: ../ref/ref.html).  If you want to understand the complete
-implementation and design rationale,  refer to the PEP for a particular new
-feature.
+Reference and the Python Reference Manual.  If you want to understand the
+complete implementation and design rationale, refer to the PEP for a particular
+new feature.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 218: A Standard Set Datatype
 ================================
 
 The new :mod:`sets` module contains an implementation of a set datatype.  The
 :class:`Set` class is for mutable sets, sets that can have members added and
 removed.  The :class:`ImmutableSet` class is for sets that can't be modified,
 and instances of :class:`ImmutableSet` can therefore be used as dictionary keys.
 Sets are built on top of dictionaries, so the elements within a set must be
 hashable.
 
@@ -109,25 +108,25 @@
    False
    >>> S1.issuperset(S2)
    True
    >>>
 
 
 .. seealso::
 
    :pep:`218` - Adding a Built-In Set Object Type
       PEP written by Greg V. Wilson. Implemented by Greg V. Wilson, Alex Martelli, and
       GvR.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-generators:
 
 PEP 255: Simple Generators
 ==========================
 
 In Python 2.2, generators were added as an optional feature, to be enabled by a
 ``from __future__ import generators`` directive.  In 2.3 generators no longer
 need to be specially enabled, and are now always present; this means that
 :keyword:`yield` is now always a keyword.  The rest of this section is a copy of
 the description of generators from the "What's New in Python 2.2" document; if
@@ -210,29 +209,29 @@
            for x in inorder(t.left):
                yield x
            yield t.label
            for x in inorder(t.right):
                yield x
 
 Two other examples in :file:`Lib/test/test_generators.py` produce solutions for
 the N-Queens problem (placing $N$ queens on an $NxN$ chess board so that no
 queen threatens another) and the Knight's Tour (a route that takes a knight to
 every square of an $NxN$ chessboard without visiting any square twice).
 
 The idea of generators comes from other programming languages, especially Icon
-(`<http://www.cs.arizona.edu/icon/>`_), where the idea of generators is central.
-In Icon, every expression and function call behaves like a generator.  One
-example from "An Overview of the Icon Programming Language" at
-`<http://www.cs.arizona.edu/icon/docs/ipd266.htm>`_ gives an idea of what this
-looks like::
+(http://www.cs.arizona.edu/icon/), where the idea of generators is central.  In
+Icon, every expression and function call behaves like a generator.  One example
+from "An Overview of the Icon Programming Language" at
+http://www.cs.arizona.edu/icon/docs/ipd266.htm gives an idea of what this looks
+like::
 
    sentence := "Store it in the neighboring harbor"
    if (i := find("or", sentence)) > 5 then write(i)
 
 In Icon the :func:`find` function returns the indexes at which the substring
 "or" is found: 3, 23, 33.  In the :keyword:`if` statement, ``i`` is first
 assigned a value of 3, but 3 is less than 5, so the comparison fails, and Icon
 retries it with the second value of 23.  23 is greater than 5, so the comparison
 now succeeds, and the code prints the value 23 to the screen.
 
 Python doesn't go nearly as far as Icon in adopting generators as a central
 concept.  Generators are considered part of the core Python language, but
@@ -240,25 +239,25 @@
 you have, feel free to ignore them. One novel feature of Python's interface as
 compared to Icon's is that a generator's state is represented as a concrete
 object (the iterator) that can be passed around to other functions or stored in
 a data structure.
 
 
 .. seealso::
 
    :pep:`255` - Simple Generators
       Written by Neil Schemenauer, Tim Peters, Magnus Lie Hetland.  Implemented mostly
       by Neil Schemenauer and Tim Peters, with other fixes from the Python Labs crew.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-encodings:
 
 PEP 263: Source Code Encodings
 ==============================
 
 Python source files can now be declared as being in different character set
 encodings.  Encodings are declared by including a specially formatted comment in
 the first or second line of the source file.  For example, a UTF-8 file can be
 declared with::
 
@@ -274,44 +273,44 @@
 The encoding declaration only affects Unicode string literals, which will be
 converted to Unicode using the specified encoding.  Note that Python identifiers
 are still restricted to ASCII characters, so you can't have variable names that
 use characters outside of the usual alphanumerics.
 
 
 .. seealso::
 
    :pep:`263` - Defining Python Source Code Encodings
       Written by Marc-André Lemburg and Martin von Löwis; implemented by Suzuki Hisao
       and Martin von Löwis.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 273: Importing Modules from ZIP Archives
 ============================================
 
 The new :mod:`zipimport` module adds support for importing modules from a ZIP-
 format archive.  You don't need to import the module explicitly; it will be
 automatically imported if a ZIP archive's filename is added to ``sys.path``.
 For example::
 
    amk@nyman:~/src/python$ unzip -l /tmp/example.zip
    Archive:  /tmp/example.zip
      Length     Date   Time    Name
     --------    ----   ----    ----
         8467  11-26-02 22:30   jwzthreading.py
     --------                   -------
         8467                   1 file
    amk@nyman:~/src/python$ ./python
-   Python 2.3 (#1, Aug 1 2003, 19:54:32) 
+   Python 2.3 (#1, Aug 1 2003, 19:54:32)
    >>> import sys
    >>> sys.path.insert(0, '/tmp/example.zip')  # Add .zip file to front of path
    >>> import jwzthreading
    >>> jwzthreading.__file__
    '/tmp/example.zip/jwzthreading.py'
    >>>
 
 An entry in ``sys.path`` can now be the filename of a ZIP archive. The ZIP
 archive can contain any kind of files, but only files named :file:`\*.py`,
 :file:`\*.pyc`, or :file:`\*.pyo` can be imported.  If an archive only contains
 :file:`\*.py` files, Python will not attempt to modify the archive by adding the
 corresponding :file:`\*.pyc` file, meaning that if a ZIP archive doesn't contain
@@ -321,25 +320,25 @@
 subdirectory; for example, the path :file:`/tmp/example.zip/lib/` would only
 import from the :file:`lib/` subdirectory within the archive.
 
 
 .. seealso::
 
    :pep:`273` - Import Modules from Zip Archives
       Written by James C. Ahlstrom,  who also provided an implementation. Python 2.3
       follows the specification in :pep:`273`,  but uses an implementation written by
       Just van Rossum  that uses the import hooks described in :pep:`302`. See section
       :ref:`section-pep302` for a description of the new import hooks.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 277: Unicode file name support for Windows NT
 =================================================
 
 On Windows NT, 2000, and XP, the system stores file names as Unicode strings.
 Traditionally, Python has represented file names as byte strings, which is
 inadequate because it renders some file names inaccessible.
 
 Python now allows using arbitrary Unicode strings (within the limitations of the
 file system) for all functions that expect file names, most notably the
 :func:`open` built-in function. If a Unicode string is passed to
@@ -355,25 +354,25 @@
 supported as file names by checking :attr:`os.path.supports_unicode_filenames`,
 a Boolean value.
 
 Under MacOS, :func:`os.listdir` may now return Unicode filenames.
 
 
 .. seealso::
 
    :pep:`277` - Unicode file name support for Windows NT
       Written by Neil Hodgson; implemented by Neil Hodgson, Martin von Löwis, and Mark
       Hammond.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 278: Universal Newline Support
 ==================================
 
 The three major operating systems used today are Microsoft Windows, Apple's
 Macintosh OS, and the various Unix derivatives.  A minor irritation of cross-
 platform work  is that these three platforms all use different characters to
 mark the ends of lines in text files.  Unix uses the linefeed (ASCII character
 10), MacOS uses the carriage return (ASCII character 13), and Windows uses a
 two-character sequence of a carriage return plus a newline.
 
@@ -390,25 +389,25 @@
 line-endings.
 
 This feature can be disabled when compiling Python by specifying the
 :option:`--without-universal-newlines` switch when running Python's
 :program:`configure` script.
 
 
 .. seealso::
 
    :pep:`278` - Universal Newline Support
       Written and implemented by Jack Jansen.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-enumerate:
 
 PEP 279: enumerate()
 ====================
 
 A new built-in function, :func:`enumerate`, will make certain loops a bit
 clearer.  ``enumerate(thing)``, where *thing* is either an iterator or a
 sequence, returns a iterator that will return ``(0, thing[0])``, ``(1,
 thing[1])``, ``(2, thing[2])``, and so forth.
 
@@ -422,25 +421,25 @@
 This can be rewritten using :func:`enumerate` as::
 
    for i, item in enumerate(L):
        # ... compute some result based on item ...
        L[i] = result
 
 
 .. seealso::
 
    :pep:`279` - The enumerate() built-in function
       Written and implemented by Raymond D. Hettinger.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 282: The logging Package
 ============================
 
 A standard package for writing logs, :mod:`logging`, has been added to Python
 2.3.  It provides a powerful and flexible mechanism for generating logging
 output which can then be filtered and processed in various ways.  A
 configuration file written in a standard format can be used to control the
 logging behavior of a program.  Python includes handlers that will write log
 records to standard error or to a file or socket, send them to the system log,
 or even e-mail them to a particular address; of course, it's also possible to
@@ -520,34 +519,33 @@
 customized.  When a :class:`Logger` instance is told to log a message, it
 creates a :class:`LogRecord` instance that is sent to any number of different
 :class:`Handler` instances.  Loggers and handlers can also have an attached list
 of filters, and each filter can cause the :class:`LogRecord` to be ignored or
 can modify the record before passing it along.  When they're finally output,
 :class:`LogRecord` instances are converted to text by a :class:`Formatter`
 class.  All of these classes can be replaced by your own specially-written
 classes.
 
 With all of these features the :mod:`logging` package should provide enough
 flexibility for even the most complicated applications.  This is only an
 incomplete overview of its features, so please see the package's reference
-documentation (XXX reference: ../lib/module-logging.html) for all of the
-details.  Reading :pep:`282` will also be helpful.
+documentation for all of the details.  Reading :pep:`282` will also be helpful.
 
 
 .. seealso::
 
    :pep:`282` - A Logging System
       Written by Vinay Sajip and Trent Mick; implemented by Vinay Sajip.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-bool:
 
 PEP 285: A Boolean Type
 =======================
 
 A Boolean type was added to Python 2.3.  Two new constants were added to the
 :mod:`__builtin__` module, :const:`True` and :const:`False`.  (:const:`True` and
 :const:`False` constants were added to the built-ins in Python 2.2.1, but the
 2.2.1 versions are simply set to integer values of 1 and 0 and aren't a
 different type.)
@@ -601,25 +599,25 @@
 
 To sum up :const:`True` and :const:`False` in a sentence: they're alternative
 ways to spell the integer values 1 and 0, with the single difference that
 :func:`str` and :func:`repr` return the strings ``'True'`` and ``'False'``
 instead of ``'1'`` and ``'0'``.
 
 
 .. seealso::
 
    :pep:`285` - Adding a bool type
       Written and implemented by GvR.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 PEP 293: Codec Error Handling Callbacks
 =======================================
 
 When encoding a Unicode string into a byte string, unencodable characters may be
 encountered.  So far, Python has allowed specifying the error processing as
 either "strict" (raising :exc:`UnicodeError`), "ignore" (skipping the
 character), or "replace" (using a question mark in the output string), with
 "strict" being the default behavior. It may be desirable to specify alternative
 processing of such errors, such as inserting an XML character reference or HTML
 entity reference into the converted string.
@@ -633,74 +631,74 @@
 either raise an exception or return a replacement string.
 
 Two additional error handlers have been implemented using this framework:
 "backslashreplace" uses Python backslash quoting to represent unencodable
 characters and "xmlcharrefreplace" emits XML character references.
 
 
 .. seealso::
 
    :pep:`293` - Codec Error Handling Callbacks
       Written and implemented by Walter Dörwald.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-pep301:
 
 PEP 301: Package Index and Metadata for Distutils
 =================================================
 
 Support for the long-requested Python catalog makes its first appearance in 2.3.
 
 The heart of the catalog is the new Distutils :command:`register` command.
 Running ``python setup.py register`` will collect the metadata describing a
 package, such as its name, version, maintainer, description, &c., and send it to
 a central catalog server.  The resulting catalog is available from
-`<http://www.python.org/pypi>`_.
+http://www.python.org/pypi.
 
 To make the catalog a bit more useful, a new optional *classifiers* keyword
 argument has been added to the Distutils :func:`setup` function.  A list of
 `Trove <http://catb.org/~esr/trove/>`_-style strings can be supplied to help
 classify the software.
 
 Here's an example :file:`setup.py` with classifiers, written to be compatible
 with older versions of the Distutils::
 
    from distutils import core
    kw = {'name': "Quixote",
          'version': "0.5.1",
          'description': "A highly Pythonic Web application framework",
          # ...
          }
 
-   if (hasattr(core, 'setup_keywords') and 
+   if (hasattr(core, 'setup_keywords') and
        'classifiers' in core.setup_keywords):
        kw['classifiers'] = \
            ['Topic :: Internet :: WWW/HTTP :: Dynamic Content',
             'Environment :: No Input/Output (Daemon)',
             'Intended Audience :: Developers'],
 
    core.setup(**kw)
 
 The full list of classifiers can be obtained by running  ``python setup.py
 register --list-classifiers``.
 
 
 .. seealso::
 
    :pep:`301` - Package Index and Metadata for Distutils
       Written and implemented by Richard Jones.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-pep302:
 
 PEP 302: New Import Hooks
 =========================
 
 While it's been possible to write custom import hooks ever since the
 :mod:`ihooks` module was introduced in Python 1.3, no one has ever been really
 happy with it because writing new import hooks is difficult and messy.  There
 have been various proposed alternatives such as the :mod:`imputil` and :mod:`iu`
 modules, but none of them has ever gained much acceptance, and none of them were
@@ -748,25 +746,25 @@
                loader = importer.find_module(fullname)
                <module> = loader.load_module(fullname)
 
    # Not found!
    raise ImportError
 
 
 .. seealso::
 
    :pep:`302` - New Import Hooks
       Written by Just van Rossum and Paul Moore. Implemented by Just van Rossum.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-pep305:
 
 PEP 305: Comma-separated Files
 ==============================
 
 Comma-separated files are a format frequently used for exporting data from
 databases and spreadsheets.  Python 2.3 adds a parser for comma-separated files.
 
 Comma-separated format is deceptively simple at first glance::
 
@@ -794,28 +792,28 @@
 Different dialects of comma-separated files can be defined and registered;
 currently there are two dialects, both used by Microsoft Excel. A separate
 :class:`csv.writer` class will generate comma-separated files from a succession
 of tuples or lists, quoting strings that contain the delimiter.
 
 
 .. seealso::
 
    :pep:`305` - CSV File API
       Written and implemented  by Kevin Altis, Dave Cole, Andrew McNamara, Skip
       Montanaro, Cliff Wells.
 
-.. % ======================================================================
+.. ======================================================================
 
 
-.. _section-pep305:
+.. _section-pep307:
 
 PEP 307: Pickle Enhancements
 ============================
 
 The :mod:`pickle` and :mod:`cPickle` modules received some attention during the
 2.3 development cycle.  In 2.2, new-style classes could be pickled without
 difficulty, but they weren't pickled very compactly; :pep:`307` quotes a trivial
 example where a new-style class results in a pickled string three times longer
 than that for a classic class.
 
 The solution was to invent a new pickle protocol.  The :func:`pickle.dumps`
 function has supported a text-or-binary flag  for a long time.  In 2.3, this
@@ -837,25 +835,25 @@
 
 As a way to compress pickles yet further, it's now possible to use integer codes
 instead of long strings to identify pickled classes. The Python Software
 Foundation will maintain a list of standardized codes; there's also a range of
 codes for private use.  Currently no codes have been specified.
 
 
 .. seealso::
 
    :pep:`307` - Extensions to the pickle protocol
       Written and implemented  by Guido van Rossum and Tim Peters.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-slices:
 
 Extended Slices
 ===============
 
 Ever since Python 1.4, the slicing syntax has supported an optional third "step"
 or "stride" argument.  For example, these are all legal Python syntax:
 ``L[1:10:2]``, ``L[:-1:1]``, ``L[::-1]``.  This was added to Python at the
 request of the developers of Numerical Python, which uses the third argument
 extensively.  However, Python's built-in list, tuple, and string sequence types
@@ -947,25 +945,25 @@
        def __getitem__(self, item):
            if isinstance(item, slice):
                indices = item.indices(len(self))
                return FakeSeq([self.calc_item(i) for i in range(*indices)])
            else:
                return self.calc_item(i)
 
 From this example you can also see that the built-in :class:`slice` object is
 now the type object for the slice type, and is no longer a function.  This is
 consistent with Python 2.2, where :class:`int`, :class:`str`, etc., underwent
 the same change.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Other Language Changes
 ======================
 
 Here are all of the changes that Python 2.3 makes to the core Python language.
 
 * The :keyword:`yield` statement is now always a keyword, as described in
   section :ref:`section-generators` of this document.
 
 * A new built-in function :func:`enumerate` was added, as described in section
   :ref:`section-enumerate` of this document.
@@ -1020,41 +1018,39 @@
      >>>
 
   There's also a new class method,  :meth:`dict.fromkeys(iterable, value)`, that
   creates a dictionary with keys taken from the supplied iterator *iterable* and
   all values set to *value*, defaulting to ``None``.
 
   (Patches contributed by Raymond Hettinger.)
 
   Also, the :func:`dict` constructor now accepts keyword arguments to simplify
   creating small dictionaries::
 
      >>> dict(red=1, blue=2, green=3, black=4)
-     {'blue': 2, 'black': 4, 'green': 3, 'red': 1}    
+     {'blue': 2, 'black': 4, 'green': 3, 'red': 1}
 
   (Contributed by Just van Rossum.)
 
 * The :keyword:`assert` statement no longer checks the ``__debug__`` flag, so
   you can no longer disable assertions by assigning to ``__debug__``. Running
   Python with the :option:`-O` switch will still generate code that doesn't
   execute any assertions.
 
 * Most type objects are now callable, so you can use them to create new objects
   such as functions, classes, and modules.  (This means that the :mod:`new` module
   can be deprecated in a future Python version, because you can now use the type
   objects available in the :mod:`types` module.) For example, you can create a new
   module object with the following code:
 
-  .. % XXX should new.py use PendingDeprecationWarning?
-
   ::
 
      >>> import types
      >>> m = types.ModuleType('abc','docstring')
      >>> m
      <module 'abc' (built-in)>
      >>> m.__doc__
      'docstring'
 
 * A new warning, :exc:`PendingDeprecationWarning` was added to indicate features
   which are in the process of being deprecated.  The warning will *not* be printed
   by default.  To check for use of features that will be deprecated in the future,
@@ -1076,27 +1072,27 @@
   encoding used by the file; Unicode strings written to the file will be
   automatically  converted to bytes using the given encoding.
 
 * The method resolution order used by new-style classes has changed, though
   you'll only notice the difference if you have a really complicated inheritance
   hierarchy.  Classic classes are unaffected by this change.  Python 2.2
   originally used a topological sort of a class's ancestors, but 2.3 now uses the
   C3 algorithm as described in the paper `"A Monotonic Superclass Linearization
   for Dylan" <http://www.webcom.com/haahr/dylan/linearization-oopsla96.html>`_. To
   understand the motivation for this change,  read Michele Simionato's article
   `"Python 2.3 Method Resolution Order" <http://www.python.org/2.3/mro.html>`_, or
   read the thread on python-dev starting with the message at
-  `<http://mail.python.org/pipermail/python-dev/2002-October/029035.html>`_.
-  Samuele Pedroni first pointed out the problem and also implemented the fix by
-  coding the C3 algorithm.
+  http://mail.python.org/pipermail/python-dev/2002-October/029035.html. Samuele
+  Pedroni first pointed out the problem and also implemented the fix by coding the
+  C3 algorithm.
 
 * Python runs multithreaded programs by switching between threads after
   executing N bytecodes.  The default value for N has been increased from 10 to
   100 bytecodes, speeding up single-threaded applications by reducing the
   switching overhead.  Some multithreaded applications may suffer slower response
   time, but that's easily fixed by setting the limit back to a lower number using
   :func:`sys.setcheckinterval(N)`. The limit can be retrieved with the new
   :func:`sys.getcheckinterval` function.
 
 * One minor but far-reaching change is that the names of extension types defined
   by the modules included with Python now contain the module and a ``'.'`` in
   front of the type name.  For example, in Python 2.2, if you created a socket and
@@ -1108,25 +1104,25 @@
 
   In 2.3, you get this::
 
      >>> s.__class__
      <type '_socket.socket'>
 
 * One of the noted incompatibilities between old- and new-style classes has been
   removed: you can now assign to the :attr:`__name__` and :attr:`__bases__`
   attributes of new-style classes.  There are some restrictions on what can be
   assigned to :attr:`__bases__` along the lines of those relating to assigning to
   an instance's :attr:`__class__` attribute.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 String Changes
 --------------
 
 * The :keyword:`in` operator now works differently for strings. Previously, when
   evaluating ``X in Y`` where *X* and *Y* are strings, *X* could only be a single
   character. That's now changed; *X* can be a string of any length, and ``X in Y``
   will return :const:`True` if *X* is a substring of *Y*.  If *X* is the empty
   string, the result is always :const:`True`. ::
 
      >>> 'ab' in 'abcd'
@@ -1172,25 +1168,25 @@
 
   (Contributed by Walter Dörwald.)
 
 * A new type object, :class:`basestring`, has been added. Both 8-bit strings and
   Unicode strings inherit from this type, so ``isinstance(obj, basestring)`` will
   return :const:`True` for either kind of string.  It's a completely abstract
   type, so you can't create :class:`basestring` instances.
 
 * Interned strings are no longer immortal and will now be garbage-collected in
   the usual way when the only reference to them is from the internal dictionary of
   interned strings.  (Implemented by Oren Tirosh.)
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Optimizations
 -------------
 
 * The creation of new-style class instances has been made much faster; they're
   now faster than classic classes!
 
 * The :meth:`sort` method of list objects has been extensively rewritten by Tim
   Peters, and the implementation is significantly faster.
 
 * Multiplication of large long integers is now much faster thanks to an
@@ -1204,25 +1200,25 @@
 
 * :func:`xrange` objects now have their own iterator, making ``for i in
   xrange(n)`` slightly faster than ``for i in range(n)``.  (Patch by Raymond
   Hettinger.)
 
 * A number of small rearrangements have been made in various hotspots to improve
   performance, such as inlining a function or removing some code.  (Implemented
   mostly by GvR, but lots of people have contributed single changes.)
 
 The net result of the 2.3 optimizations is that Python 2.3 runs the  pystone
 benchmark around 25% faster than Python 2.2.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 New, Improved, and Deprecated Modules
 =====================================
 
 As usual, Python's standard library received a number of enhancements and bug
 fixes.  Here's a partial list of the most notable changes, sorted alphabetically
 by module name. Consult the :file:`Misc/NEWS` file in the source tree for a more
 complete list of changes, or look through the CVS logs for all the details.
 
 * The :mod:`array` module now supports arrays of Unicode characters using the
   ``'u'`` format character.  Arrays also now support using the ``+=`` assignment
@@ -1298,64 +1294,63 @@
      >>> import grp
      >>> g = grp.getgrnam('amk')
      >>> g.gr_name, g.gr_gid
      ('amk', 500)
 
 * The :mod:`gzip` module can now handle files exceeding 2 GiB.
 
 * The new :mod:`heapq` module contains an implementation of a heap queue
   algorithm.  A heap is an array-like data structure that keeps items in a
   partially sorted order such that, for every index *k*, ``heap[k] <=
   heap[2*k+1]`` and ``heap[k] <= heap[2*k+2]``.  This makes it quick to remove the
   smallest item, and inserting a new item while maintaining the heap property is
-  O(lg n).  (See `<http://www.nist.gov/dads/HTML/priorityque.html>`_ for more
+  O(lg n).  (See http://www.nist.gov/dads/HTML/priorityque.html for more
   information about the priority queue data structure.)
 
   The :mod:`heapq` module provides :func:`heappush` and :func:`heappop` functions
   for adding and removing items while maintaining the heap property on top of some
   other mutable Python sequence type.  Here's an example that uses a Python list::
 
      >>> import heapq
      >>> heap = []
      >>> for item in [3, 7, 5, 11, 1]:
      ...    heapq.heappush(heap, item)
      ...
      >>> heap
      [1, 3, 5, 11, 7]
      >>> heapq.heappop(heap)
      1
      >>> heapq.heappop(heap)
      3
      >>> heap
      [5, 7, 11]
 
   (Contributed by Kevin O'Connor.)
 
 * The IDLE integrated development environment has been updated using the code
-  from the IDLEfork project (`<http://idlefork.sf.net>`_).  The most notable
-  feature is that the code being developed is now executed in a subprocess,
-  meaning that there's no longer any need for manual ``reload()`` operations.
-  IDLE's core code has been incorporated into the standard library as the
-  :mod:`idlelib` package.
+  from the IDLEfork project (http://idlefork.sf.net).  The most notable feature is
+  that the code being developed is now executed in a subprocess, meaning that
+  there's no longer any need for manual ``reload()`` operations. IDLE's core code
+  has been incorporated into the standard library as the :mod:`idlelib` package.
 
 * The :mod:`imaplib` module now supports IMAP over SSL. (Contributed by Piers
   Lauder and Tino Lange.)
 
 * The :mod:`itertools` contains a number of useful functions for use with
   iterators, inspired by various functions provided by the ML and Haskell
   languages.  For example, ``itertools.ifilter(predicate, iterator)`` returns all
   elements in the iterator for which the function :func:`predicate` returns
   :const:`True`, and ``itertools.repeat(obj, N)`` returns ``obj`` *N* times.
   There are a number of other functions in the module; see the package's reference
-  documentation (XXX reference: ../lib/module-itertools.html) for details.
+  documentation for details.
   (Contributed by Raymond Hettinger.)
 
 * Two new functions in the :mod:`math` module, :func:`degrees(rads)` and
   :func:`radians(degs)`, convert between radians and degrees.  Other functions in
   the :mod:`math` module such as :func:`math.sin` and :func:`math.cos` have always
   required input values measured in radians.  Also, an optional *base* argument
   was added to :func:`math.log` to make it easier to compute logarithms for bases
   other than ``e`` and ``10``.  (Contributed by Raymond Hettinger.)
 
 * Several new POSIX functions (:func:`getpgid`, :func:`killpg`, :func:`lchown`,
   :func:`loadavg`, :func:`major`, :func:`makedev`, :func:`minor`, and
   :func:`mknod`) were added to the :mod:`posix` module that underlies the
@@ -1498,26 +1493,25 @@
      Not a whit, we defy augury: there's
      a special providence in the fall of
      a sparrow. If it be now, 'tis not
      to come; if it be not to come, it
      will be now; if it be not now, yet
      it will come: the readiness is all.
      >>>
 
   The module also contains a :class:`TextWrapper` class that actually implements
   the text wrapping strategy.   Both the :class:`TextWrapper` class and the
   :func:`wrap` and :func:`fill` functions support a number of additional keyword
   arguments for fine-tuning the formatting; consult the module's documentation
-  (XXX reference: ../lib/module-textwrap.html) for details. (Contributed by Greg
-  Ward.)
+  for details. (Contributed by Greg Ward.)
 
 * The :mod:`thread` and :mod:`threading` modules now have companion modules,
   :mod:`dummy_thread` and :mod:`dummy_threading`, that provide a do-nothing
   implementation of the :mod:`thread` module's interface for platforms where
   threads are not supported.  The intention is to simplify thread-aware modules
   (ones that *don't* rely on threads to run) by putting the following code at the
   top::
 
      try:
          import threading as _threading
      except ImportError:
          import dummy_threading as _threading
@@ -1558,28 +1552,26 @@
 
 * The :mod:`Tix` module has received various bug fixes and updates for the
   current version of the Tix package.
 
 * The :mod:`Tkinter` module now works with a thread-enabled  version of Tcl.
   Tcl's threading model requires that widgets only be accessed from the thread in
   which they're created; accesses from another thread can cause Tcl to panic.  For
   certain Tcl interfaces, :mod:`Tkinter` will now automatically avoid this  when a
   widget is accessed from a different thread by marshalling a command, passing it
   to the correct thread, and waiting for the results.  Other interfaces can't be
   handled automatically but :mod:`Tkinter` will now raise an exception on such an
   access so that you can at least find out about the problem.  See
-  `<http://mail.python.org/pipermail/python-dev/2002-December/031107.html>`_ for a
-  more detailed explanation of this change.  (Implemented by Martin von Löwis.)
-
-  .. % 
+  http://mail.python.org/pipermail/python-dev/2002-December/031107.html for a more
+  detailed explanation of this change.  (Implemented by Martin von Löwis.)
 
 * Calling Tcl methods through :mod:`_tkinter` no longer  returns only strings.
   Instead, if Tcl returns other objects those objects are converted to their
   Python equivalent, if one exists, or wrapped with a :class:`_tkinter.Tcl_Obj`
   object if no Python equivalent exists. This behavior can be controlled through
   the :meth:`wantobjects` method of :class:`tkapp` objects.
 
   When using :mod:`_tkinter` through the :mod:`Tkinter` module (as most Tkinter
   applications will), this feature is always activated. It should not cause
   compatibility problems, since Tkinter would always convert string results to
   Python types where possible.
 
@@ -1621,25 +1613,25 @@
      ...         except ValueError:
      ...             self.keylist.append(key)
      ...             self.valuelist.append(value)
      ...     def __delitem__(self, key):
      ...         try:
      ...             i = self.keylist.index(key)
      ...         except ValueError:
      ...             raise KeyError
      ...         self.keylist.pop(i)
      ...         self.valuelist.pop(i)
      ...     def keys(self):
      ...         return list(self.keylist)
-     ... 
+     ...
      >>> s = SeqDict()
      >>> dir(s)      # See that other dictionary methods are implemented
      ['__cmp__', '__contains__', '__delitem__', '__doc__', '__getitem__',
       '__init__', '__iter__', '__len__', '__module__', '__repr__',
       '__setitem__', 'clear', 'get', 'has_key', 'items', 'iteritems',
       'iterkeys', 'itervalues', 'keylist', 'keys', 'pop', 'popitem',
       'setdefault', 'update', 'valuelist', 'values']
 
   (Contributed by Raymond Hettinger.)
 
 * The DOM implementation in :mod:`xml.dom.minidom` can now generate XML output
   in a particular encoding by providing an optional encoding argument to the
@@ -1655,35 +1647,36 @@
   servers. Run it in demo mode (as a program) to see it in action.   Pointing the
   Web browser to the RPC server produces pydoc-style documentation; pointing
   xmlrpclib to the server allows invoking the actual methods. (Contributed by
   Brian Quinlan.)
 
 * Support for internationalized domain names (RFCs 3454, 3490, 3491, and 3492)
   has been added. The "idna" encoding can be used to convert between a Unicode
   domain name and the ASCII-compatible encoding (ACE) of that name. ::
 
      >{}>{}> u"www.Alliancefrançaise.nu".encode("idna")
      'www.xn--alliancefranaise-npb.nu'
 
-  The :mod:`socket` module has also been extended to transparently convert Unicode
-  hostnames to the ACE version before passing them to the C library.  Modules that
-  deal with hostnames such as :mod:`httplib` and :mod:`ftplib`) also support
-  Unicode host names; :mod:`httplib` also sends HTTP ``Host`` headers using the
-  ACE version of the domain name.  :mod:`urllib` supports Unicode URLs with non-
-  ASCII host names as long as the ``path`` part of the URL is ASCII only.
+  The :mod:`socket` module has also been extended to transparently convert
+  Unicode hostnames to the ACE version before passing them to the C library.
+  Modules that deal with hostnames such as :mod:`httplib` and :mod:`ftplib`)
+  also support Unicode host names; :mod:`httplib` also sends HTTP ``Host``
+  headers using the ACE version of the domain name.  :mod:`urllib` supports
+  Unicode URLs with non-ASCII host names as long as the ``path`` part of the URL
+  is ASCII only.
 
   To implement this change, the :mod:`stringprep` module, the  ``mkstringprep``
   tool and the ``punycode`` encoding have been added.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Date/Time Type
 --------------
 
 Date and time types suitable for expressing timestamps were added as the
 :mod:`datetime` module.  The types don't support different calendars or many
 fancy features, and just stick to the basics of representing time.
 
 The three primary types are: :class:`date`, representing a day, month, and year;
 :class:`time`, consisting of hour, minute, and second; and :class:`datetime`,
 which contains all the attributes of both :class:`date` and :class:`time`.
@@ -1717,28 +1710,28 @@
    datetime.datetime(2002, 12, 30, 22, 15, 38, 827738)
    >>> d.replace(year=2001, hour = 12)
    datetime.datetime(2001, 12, 30, 12, 15, 38, 827738)
    >>>
 
 Instances can be compared, hashed, and converted to strings (the result is the
 same as that of :meth:`isoformat`).  :class:`date` and :class:`datetime`
 instances can be subtracted from each other, and added to :class:`timedelta`
 instances.  The largest missing feature is that there's no standard library
 support for parsing strings and getting back a :class:`date` or
 :class:`datetime`.
 
-For more information, refer to the module's reference documentation (XXX
-reference: ../lib/module-datetime.html). (Contributed by Tim Peters.)
+For more information, refer to the module's reference documentation.
+(Contributed by Tim Peters.)
 
-.. % ======================================================================
+.. ======================================================================
 
 
 The optparse Module
 -------------------
 
 The :mod:`getopt` module provides simple parsing of command-line arguments.  The
 new :mod:`optparse` module (originally named Optik) provides more elaborate
 command-line parsing that follows the Unix conventions, automatically creates
 the output for :option:`--help`, and can perform different actions for different
 options.
 
 You start by creating an instance of :class:`OptionParser` and telling it what
@@ -1777,35 +1770,33 @@
 
 The help message is automatically generated for you::
 
    $ ./python opt.py --help
    usage: opt.py [options]
 
    options:
      -h, --help            show this help message and exit
      -iINPUT, --input=INPUT
                            set input filename
      -lLENGTH, --length=LENGTH
                            set maximum length of output
-   $ 
+   $
 
-See the module's documentation (XXX reference: ../lib/module-optparse.html) for
-more details.
+See the module's documentation for more details.
 
-.. % $ prevent Emacs tex-mode from getting confused
 
 Optik was written by Greg Ward, with suggestions from the readers of the Getopt
 SIG.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-pymalloc:
 
 Pymalloc: A Specialized Object Allocator
 ========================================
 
 Pymalloc, a specialized object allocator written by Vladimir Marangozov, was a
 feature added to Python 2.1.  Pymalloc is intended to be faster than the system
 :cfunc:`malloc` and to have less memory overhead for allocation patterns typical
 of Python programs. The allocator uses C's :cfunc:`malloc` function to get large
 pools of memory and then fulfills smaller memory requests from these pools.
@@ -1860,25 +1851,25 @@
 the 2.3 interfaces to memory allocation while compiling against any version of
 Python since 1.5.2.  You would copy the file from Python's source distribution
 and bundle it with the source of your extension.
 
 
 .. seealso::
 
    http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Objects/obmalloc.c
       For the full details of the pymalloc implementation, see the comments at the top
       of the file :file:`Objects/obmalloc.c` in the Python source code.  The above
       link points to the file within the SourceForge CVS browser.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Build and C API Changes
 =======================
 
 Changes to Python's build process and to the C API include:
 
 * The cycle detection implementation used by the garbage collection has proven
   to be stable, so it's now been made mandatory.  You can no longer compile Python
   without it, and the :option:`--with-cycle-gc` switch to :program:`configure` has
   been removed.
 
@@ -1922,51 +1913,51 @@
   method's :ctype:`PyMethodDef` structure.
 
 * Python now includes a copy of the Expat XML parser's source code, removing any
   dependence on a system version or local installation of Expat.
 
 * If you dynamically allocate type objects in your extension, you should be
   aware of a change in the rules relating to the :attr:`__module__` and
   :attr:`__name__` attributes.  In summary, you will want to ensure the type's
   dictionary contains a ``'__module__'`` key; making the module name the part of
   the type name leading up to the final period will no longer have the desired
   effect.  For more detail, read the API reference documentation or the  source.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Port-Specific Changes
 ---------------------
 
 Support for a port to IBM's OS/2 using the EMX runtime environment was merged
 into the main Python source tree.  EMX is a POSIX emulation layer over the OS/2
 system APIs.  The Python port for EMX tries to support all the POSIX-like
 capability exposed by the EMX runtime, and mostly succeeds; :func:`fork` and
 :func:`fcntl` are restricted by the limitations of the underlying emulation
 layer.  The standard OS/2 port, which uses IBM's Visual Age compiler, also
 gained support for case-sensitive import semantics as part of the integration of
 the EMX port into CVS.  (Contributed by Andrew MacIntyre.)
 
 On MacOS, most toolbox modules have been weaklinked to improve backward
 compatibility.  This means that modules will no longer fail to load if a single
 routine is missing on the current OS version. Instead calling the missing
 routine will raise an exception. (Contributed by Jack Jansen.)
 
 The RPM spec files, found in the :file:`Misc/RPM/` directory in the Python
 source distribution, were updated for 2.3.  (Contributed by Sean Reifschneider.)
 
 Other new platforms now supported by Python include AtheOS
-(`<http://www.atheos.cx/>`_), GNU/Hurd, and OpenVMS.
+(http://www.atheos.cx/), GNU/Hurd, and OpenVMS.
 
-.. % ======================================================================
+.. ======================================================================
 
 
 .. _section-other:
 
 Other Changes and Fixes
 =======================
 
 As usual, there were a bunch of other improvements and bugfixes scattered
 throughout the source tree.  A search through the CVS change logs finds there
 were 523 patches applied and 514 bugs fixed between Python 2.2 and 2.3.  Both
 figures are likely to be underestimates.
 
@@ -1999,25 +1990,25 @@
   from a slight speed up when Python is run without :option:`-O`.
 
   C extensions that access the :attr:`f_lineno` field of frame objects should
   instead call ``PyCode_Addr2Line(f->f_code, f->f_lasti)``. This will have the
   added effect of making the code work as desired under "python -O" in earlier
   versions of Python.
 
   A nifty new feature is that trace functions can now assign to the
   :attr:`f_lineno` attribute of frame objects, changing the line that will be
   executed next.  A ``jump`` command has been added to the :mod:`pdb` debugger
   taking advantage of this new feature. (Implemented by Richie Hindle.)
 
-.. % ======================================================================
+.. ======================================================================
 
 
 Porting to Python 2.3
 =====================
 
 This section lists previously described changes that may require changes to your
 code:
 
 * :keyword:`yield` is now always a keyword; if it's used as a variable name in
   your code, a different name must be chosen.
 
 * For strings *X* and *Y*, ``X in Y`` now works if *X* is more than one
@@ -2038,51 +2029,49 @@
 
 * Large octal and hex literals such as ``0xffffffff`` now trigger a
   :exc:`FutureWarning`. Currently they're stored as 32-bit numbers and result in a
   negative value, but in Python 2.4 they'll become positive long integers.
 
   There are a few ways to fix this warning.  If you really need a positive number,
   just add an ``L`` to the end of the literal.  If you're trying to get a 32-bit
   integer with low bits set and have previously used an expression such as ``~(1
   << 31)``, it's probably clearest to start with all bits set and clear the
   desired upper bits. For example, to clear just the top bit (bit 31), you could
   write ``0xffffffffL &~(1L<<31)``.
 
-  .. % The empty groups below prevent conversion to guillemets.
-
 * You can no longer disable assertions by assigning to ``__debug__``.
 
 * The Distutils :func:`setup` function has gained various new keyword arguments
   such as *depends*.  Old versions of the Distutils will abort if passed unknown
   keywords.  A solution is to check for the presence of the new
   :func:`get_distutil_options` function in your :file:`setup.py` and only uses the
   new keywords with a version of the Distutils that supports them::
 
      from distutils import core
 
      kw = {'sources': 'foo.c', ...}
      if hasattr(core, 'get_distutil_options'):
          kw['depends'] = ['foo.h']
      ext = Extension(**kw)
 
 * Using ``None`` as a variable name will now result in a :exc:`SyntaxWarning`
   warning.
 
 * Names of extension types defined by the modules included with Python now
   contain the module and a ``'.'`` in front of the type name.
 
-.. % ======================================================================
+.. ======================================================================
 
 
-.. _acks:
+.. _23acks:
 
 Acknowledgements
 ================
 
 The author would like to thank the following people for offering suggestions,
 corrections and assistance with various drafts of this article: Jeff Bauer,
 Simon Brunning, Brett Cannon, Michael Chermside, Andrew Dalke, Scott David
 Daniels, Fred L. Drake, Jr., David Fraser,  Kelly Gerber, Raymond Hettinger,
 Michael Hudson, Chris Lambert, Detlef Lannert, Martin von Löwis, Andrew
 MacIntyre, Lalo Martins, Chad Netzer, Gustavo Niemeyer, Neal Norwitz, Hans
 Nowak, Chris Reedy, Francesco Ricciardi, Vinay Sajip, Neil Schemenauer, Roman
 Suzi, Jason Tishler, Just van Rossum.
