diff --git a/Doc/library/argparse.rst b/Doc/library/argparse.rst
index 6bd011b..0ea8195 100644
--- a/Doc/library/argparse.rst
+++ b/Doc/library/argparse.rst
@@ -1,5 +1,5 @@
-:mod:`argparse` -- Parser for command line options, arguments and sub-commands
-==============================================================================
+:mod:`argparse` --- Parser for command line options, arguments and sub-commands
+===============================================================================
 
 .. module:: argparse
    :synopsis: Command-line option and argument parsing library.
@@ -14,6 +14,7 @@
 module also automatically generates help and usage messages and issues errors
 when users give the program invalid arguments.
 
+
 Example
 -------
 
@@ -64,6 +65,7 @@
 
 The following sections walk you through this example.
 
+
 Creating a parser
 ^^^^^^^^^^^^^^^^^
 
@@ -97,6 +99,7 @@
 either the :func:`sum` function, if ``--sum`` was specified at the command line,
 or the :func:`max` function if it was not.
 
+
 Parsing arguments
 ^^^^^^^^^^^^^^^^^
 
@@ -248,7 +251,6 @@
      +h, ++help  show this help message and exit
 
 
-
 prefix_chars
 ^^^^^^^^^^^^
 
@@ -295,6 +297,7 @@
 The ``fromfile_prefix_chars=`` argument defaults to ``None``, meaning that
 arguments will never be treated as file references.
 
+
 argument_default
 ^^^^^^^^^^^^^^^^
 
@@ -594,6 +597,7 @@
 
 The following sections describe how each of these are used.
 
+
 name or flags
 ^^^^^^^^^^^^^
 
@@ -623,6 +627,7 @@
    usage: PROG [-h] [-f FOO] bar
    PROG: error: too few arguments
 
+
 action
 ^^^^^^
 
@@ -767,8 +772,10 @@
   output files::
 
      >>> parser = argparse.ArgumentParser()
-     >>> parser.add_argument('infile', nargs='?', type=argparse.FileType('r'), default=sys.stdin)
-     >>> parser.add_argument('outfile', nargs='?', type=argparse.FileType('w'), default=sys.stdout)
+     >>> parser.add_argument('infile', nargs='?', type=argparse.FileType('r'),
+     ...                     default=sys.stdin)
+     >>> parser.add_argument('outfile', nargs='?', type=argparse.FileType('w'),
+     ...                     default=sys.stdout)
      >>> parser.parse_args(['input.txt', 'output.txt'])
      Namespace(infile=<open file 'input.txt', mode 'r' at 0x...>, outfile=<open file 'output.txt', mode 'w' at 0x...>)
      >>> parser.parse_args([])
@@ -1128,7 +1135,7 @@
 The parse_args() method
 -----------------------
 
-.. method:: ArgumentParser.parse_args([args], [namespace])
+.. method:: ArgumentParser.parse_args(args=None, namespace=None)
 
    Convert argument strings to objects and assign them as attributes of the
    namespace.  Return the populated namespace.
@@ -1140,6 +1147,7 @@
    By default, the arg strings are taken from :data:`sys.argv`, and a new empty
    :class:`Namespace` object is created for the attributes.
 
+
 Option value syntax
 ^^^^^^^^^^^^^^^^^^^
 
@@ -1503,7 +1511,7 @@
 Argument groups
 ^^^^^^^^^^^^^^^
 
-.. method:: ArgumentParser.add_argument_group([title], [description])
+.. method:: ArgumentParser.add_argument_group(title=None, description=None)
 
    By default, :class:`ArgumentParser` groups command-line arguments into
    "positional arguments" and "optional arguments" when displaying help
@@ -1527,7 +1535,7 @@
    :class:`ArgumentParser`.  When an argument is added to the group, the parser
    treats it just like a normal argument, but displays the argument in a
    separate group for help messages.  The :meth:`add_argument_group` method
-   accepts ``title`` and ``description`` arguments which can be used to
+   accepts *title* and *description* arguments which can be used to
    customize this display::
 
      >>> parser = argparse.ArgumentParser(prog='PROG', add_help=False)
@@ -1555,7 +1563,7 @@
 Mutual exclusion
 ^^^^^^^^^^^^^^^^
 
-.. method:: add_mutually_exclusive_group([required=False])
+.. method:: add_mutually_exclusive_group(required=False)
 
    Create a mutually exclusive group. argparse will make sure that only one of
    the arguments in the mutually exclusive group was present on the command
@@ -1573,7 +1581,7 @@
      usage: PROG [-h] [--foo | --bar]
      PROG: error: argument --bar: not allowed with argument --foo
 
-   The :meth:`add_mutually_exclusive_group` method also accepts a ``required``
+   The :meth:`add_mutually_exclusive_group` method also accepts a *required*
    argument, to indicate that at least one of the mutually exclusive arguments
    is required::
 
@@ -1586,7 +1594,7 @@
      PROG: error: one of the arguments --foo --bar is required
 
    Note that currently mutually exclusive argument groups do not support the
-   ``title`` and ``description`` arguments of :meth:`add_argument_group`.
+   *title* and *description* arguments of :meth:`add_argument_group`.
 
 
 Parser defaults
@@ -1637,37 +1645,36 @@
 and printing any usage or error messages.  However, several formatting methods
 are available:
 
-.. method:: ArgumentParser.print_usage([file]):
+.. method:: ArgumentParser.print_usage(file=None)
 
    Print a brief description of how the :class:`ArgumentParser` should be
-   invoked on the command line.  If ``file`` is not present, ``sys.stderr`` is
+   invoked on the command line.  If *file* is ``None``, :data:`sys.stderr` is
    assumed.
 
-.. method:: ArgumentParser.print_help([file]):
+.. method:: ArgumentParser.print_help(file=None)
 
    Print a help message, including the program usage and information about the
-   arguments registered with the :class:`ArgumentParser`.  If ``file`` is not
-   present, ``sys.stderr`` is assumed.
+   arguments registered with the :class:`ArgumentParser`.  If *file* is
+   ``None``, :data:`sys.stderr` is assumed.
 
 There are also variants of these methods that simply return a string instead of
 printing it:
 
-.. method:: ArgumentParser.format_usage():
+.. method:: ArgumentParser.format_usage()
 
    Return a string containing a brief description of how the
    :class:`ArgumentParser` should be invoked on the command line.
 
-.. method:: ArgumentParser.format_help():
+.. method:: ArgumentParser.format_help()
 
    Return a string containing a help message, including the program usage and
    information about the arguments registered with the :class:`ArgumentParser`.
 
 
-
 Partial parsing
 ^^^^^^^^^^^^^^^
 
-.. method:: ArgumentParser.parse_known_args([args], [namespace])
+.. method:: ArgumentParser.parse_known_args(args=None, namespace=None)
 
 Sometimes a script may only parse a few of the command line arguments, passing
 the remaining arguments on to another script or program. In these cases, the
@@ -1690,12 +1697,12 @@
 
 .. method:: ArgumentParser.convert_arg_line_to_args(arg_line)
 
-   Arguments that are read from a file (see the ``fromfile_prefix_chars``
+   Arguments that are read from a file (see the *fromfile_prefix_chars*
    keyword argument to the :class:`ArgumentParser` constructor) are read one
    argument per line. :meth:`convert_arg_line_to_args` can be overriden for
    fancier reading.
 
-   This method takes a single argument ``arg_line`` which is a string read from
+   This method takes a single argument *arg_line* which is a string read from
    the argument file.  It returns a list of arguments parsed from this string.
    The method is called once per line read from the argument file, in order.
 
@@ -1709,6 +1716,20 @@
             yield arg
 
 
+Exiting methods
+^^^^^^^^^^^^^^^
+
+.. method:: ArgumentParser.exit(status=0, message=None)
+
+   This method terminates the program, exiting with the specified *status*
+   and, if given, it prints a *message* before that.
+
+.. method:: ArgumentParser.error(message)
+
+   This method prints a usage message including the *message* to the
+   standard output and terminates the program with a status code of 2.
+
+
 .. _argparse-from-optparse:
 
 Upgrading optparse code
diff --git a/Doc/library/base64.rst b/Doc/library/base64.rst
index 084660d..ab85436 100644
--- a/Doc/library/base64.rst
+++ b/Doc/library/base64.rst
@@ -1,4 +1,3 @@
-
 :mod:`base64` --- RFC 3548: Base16, Base32, Base64 Data Encodings
 =================================================================
 
diff --git a/Doc/library/dis.rst b/Doc/library/dis.rst
index ac8d653..9addfe7 100644
--- a/Doc/library/dis.rst
+++ b/Doc/library/dis.rst
@@ -99,7 +99,7 @@
 
 .. data:: opmap
 
-   Dictionary mapping bytecodes to operation names.
+   Dictionary mapping operation names to bytecodes.
 
 
 .. data:: cmp_op
diff --git a/Doc/library/hmac.rst b/Doc/library/hmac.rst
index 8b3b92b..480d0a7 100644
--- a/Doc/library/hmac.rst
+++ b/Doc/library/hmac.rst
@@ -19,10 +19,6 @@
    is made. *digestmod* is the digest constructor or module for the HMAC object to
    use. It defaults to  the :func:`hashlib.md5` constructor.
 
-   .. note::
-
-      The md5 hash has known weaknesses but remains the default for backwards
-      compatibility. Choose a better one for your application.
 
 An HMAC object has the following methods:
 
diff --git a/Doc/library/os.rst b/Doc/library/os.rst
index b920d4e..194a0c4 100644
--- a/Doc/library/os.rst
+++ b/Doc/library/os.rst
@@ -1679,15 +1679,15 @@
 
 .. function:: _exit(n)
 
-   Exit to the system with status *n*, without calling cleanup handlers, flushing
+   Exit the process with status *n*, without calling cleanup handlers, flushing
    stdio buffers, etc.
 
    Availability: Unix, Windows.
 
    .. note::
 
-      The standard way to exit is ``sys.exit(n)``. :func:`_exit` should normally only
-      be used in the child process after a :func:`fork`.
+      The standard way to exit is ``sys.exit(n)``.  :func:`_exit` should
+      normally only be used in the child process after a :func:`fork`.
 
 The following exit codes are defined and can be used with :func:`_exit`,
 although they are not required.  These are typically used for system programs
diff --git a/Doc/library/parser.rst b/Doc/library/parser.rst
index 8fba6df..9049c82 100644
--- a/Doc/library/parser.rst
+++ b/Doc/library/parser.rst
@@ -322,22 +322,8 @@
    Same as ``st2tuple(st, line_info)``.
 
 
-.. _st-examples:
-
-Examples
---------
-
-.. index:: builtin: compile
-
-The parser modules allows operations to be performed on the parse tree of Python
-source code before the :term:`bytecode` is generated, and provides for inspection of the
-parse tree for information gathering purposes. Two examples are presented.  The
-simple example demonstrates emulation of the :func:`compile` built-in function
-and the complex example shows the use of a parse tree for information discovery.
-
-
-Emulation of :func:`compile`
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Example: Emulation of :func:`compile`
+-------------------------------------
 
 While many useful operations may take place between parsing and bytecode
 generation, the simplest operation is to do nothing.  For this purpose, using
@@ -371,322 +357,3 @@
    def load_expression(source_string):
        st = parser.expr(source_string)
        return st, st.compile()
-
-
-Information Discovery
-^^^^^^^^^^^^^^^^^^^^^
-
-.. index::
-   single: string; documentation
-   single: docstrings
-
-Some applications benefit from direct access to the parse tree.  The remainder
-of this section demonstrates how the parse tree provides access to module
-documentation defined in docstrings without requiring that the code being
-examined be loaded into a running interpreter via :keyword:`import`.  This can
-be very useful for performing analyses of untrusted code.
-
-Generally, the example will demonstrate how the parse tree may be traversed to
-distill interesting information.  Two functions and a set of classes are
-developed which provide programmatic access to high level function and class
-definitions provided by a module.  The classes extract information from the
-parse tree and provide access to the information at a useful semantic level, one
-function provides a simple low-level pattern matching capability, and the other
-function defines a high-level interface to the classes by handling file
-operations on behalf of the caller.  All source files mentioned here which are
-not part of the Python installation are located in the :file:`Demo/parser/`
-directory of the distribution.
-
-The dynamic nature of Python allows the programmer a great deal of flexibility,
-but most modules need only a limited measure of this when defining classes,
-functions, and methods.  In this example, the only definitions that will be
-considered are those which are defined in the top level of their context, e.g.,
-a function defined by a :keyword:`def` statement at column zero of a module, but
-not a function defined within a branch of an :keyword:`if` ... :keyword:`else`
-construct, though there are some good reasons for doing so in some situations.
-Nesting of definitions will be handled by the code developed in the example.
-
-To construct the upper-level extraction methods, we need to know what the parse
-tree structure looks like and how much of it we actually need to be concerned
-about.  Python uses a moderately deep parse tree so there are a large number of
-intermediate nodes.  It is important to read and understand the formal grammar
-used by Python.  This is specified in the file :file:`Grammar/Grammar` in the
-distribution. Consider the simplest case of interest when searching for
-docstrings: a module consisting of a docstring and nothing else.  (See file
-:file:`docstring.py`.) ::
-
-   """Some documentation.
-   """
-
-Using the interpreter to take a look at the parse tree, we find a bewildering
-mass of numbers and parentheses, with the documentation buried deep in nested
-tuples. ::
-
-   >>> import parser
-   >>> import pprint
-   >>> st = parser.suite(open('docstring.py').read())
-   >>> tup = st.totuple()
-   >>> pprint.pprint(tup)
-   (257,
-    (264,
-     (265,
-      (266,
-       (267,
-        (307,
-         (287,
-          (288,
-           (289,
-            (290,
-             (292,
-              (293,
-               (294,
-                (295,
-                 (296,
-                  (297,
-                   (298,
-                    (299,
-                     (300, (3, '"""Some documentation.\n"""'))))))))))))))))),
-      (4, ''))),
-    (4, ''),
-    (0, ''))
-
-The numbers at the first element of each node in the tree are the node types;
-they map directly to terminal and non-terminal symbols in the grammar.
-Unfortunately, they are represented as integers in the internal representation,
-and the Python structures generated do not change that.  However, the
-:mod:`symbol` and :mod:`token` modules provide symbolic names for the node types
-and dictionaries which map from the integers to the symbolic names for the node
-types.
-
-In the output presented above, the outermost tuple contains four elements: the
-integer ``257`` and three additional tuples.  Node type ``257`` has the symbolic
-name :const:`file_input`.  Each of these inner tuples contains an integer as the
-first element; these integers, ``264``, ``4``, and ``0``, represent the node
-types :const:`stmt`, :const:`NEWLINE`, and :const:`ENDMARKER`, respectively.
-Note that these values may change depending on the version of Python you are
-using; consult :file:`symbol.py` and :file:`token.py` for details of the
-mapping.  It should be fairly clear that the outermost node is related primarily
-to the input source rather than the contents of the file, and may be disregarded
-for the moment.  The :const:`stmt` node is much more interesting.  In
-particular, all docstrings are found in subtrees which are formed exactly as
-this node is formed, with the only difference being the string itself.  The
-association between the docstring in a similar tree and the defined entity
-(class, function, or module) which it describes is given by the position of the
-docstring subtree within the tree defining the described structure.
-
-By replacing the actual docstring with something to signify a variable component
-of the tree, we allow a simple pattern matching approach to check any given
-subtree for equivalence to the general pattern for docstrings.  Since the
-example demonstrates information extraction, we can safely require that the tree
-be in tuple form rather than list form, allowing a simple variable
-representation to be ``['variable_name']``.  A simple recursive function can
-implement the pattern matching, returning a Boolean and a dictionary of variable
-name to value mappings.  (See file :file:`example.py`.) ::
-
-   from types import ListType, TupleType
-
-   def match(pattern, data, vars=None):
-       if vars is None:
-           vars = {}
-       if type(pattern) is ListType:
-           vars[pattern[0]] = data
-           return 1, vars
-       if type(pattern) is not TupleType:
-           return (pattern == data), vars
-       if len(data) != len(pattern):
-           return 0, vars
-       for pattern, data in map(None, pattern, data):
-           same, vars = match(pattern, data, vars)
-           if not same:
-               break
-       return same, vars
-
-Using this simple representation for syntactic variables and the symbolic node
-types, the pattern for the candidate docstring subtrees becomes fairly readable.
-(See file :file:`example.py`.) ::
-
-   import symbol
-   import token
-
-   DOCSTRING_STMT_PATTERN = (
-       symbol.stmt,
-       (symbol.simple_stmt,
-        (symbol.small_stmt,
-         (symbol.expr_stmt,
-          (symbol.testlist,
-           (symbol.test,
-            (symbol.and_test,
-             (symbol.not_test,
-              (symbol.comparison,
-               (symbol.expr,
-                (symbol.xor_expr,
-                 (symbol.and_expr,
-                  (symbol.shift_expr,
-                   (symbol.arith_expr,
-                    (symbol.term,
-                     (symbol.factor,
-                      (symbol.power,
-                       (symbol.atom,
-                        (token.STRING, ['docstring'])
-                        )))))))))))))))),
-        (token.NEWLINE, '')
-        ))
-
-Using the :func:`match` function with this pattern, extracting the module
-docstring from the parse tree created previously is easy::
-
-   >>> found, vars = match(DOCSTRING_STMT_PATTERN, tup[1])
-   >>> found
-   1
-   >>> vars
-   {'docstring': '"""Some documentation.\n"""'}
-
-Once specific data can be extracted from a location where it is expected, the
-question of where information can be expected needs to be answered.  When
-dealing with docstrings, the answer is fairly simple: the docstring is the first
-:const:`stmt` node in a code block (:const:`file_input` or :const:`suite` node
-types).  A module consists of a single :const:`file_input` node, and class and
-function definitions each contain exactly one :const:`suite` node.  Classes and
-functions are readily identified as subtrees of code block nodes which start
-with ``(stmt, (compound_stmt, (classdef, ...`` or ``(stmt, (compound_stmt,
-(funcdef, ...``.  Note that these subtrees cannot be matched by :func:`match`
-since it does not support multiple sibling nodes to match without regard to
-number.  A more elaborate matching function could be used to overcome this
-limitation, but this is sufficient for the example.
-
-Given the ability to determine whether a statement might be a docstring and
-extract the actual string from the statement, some work needs to be performed to
-walk the parse tree for an entire module and extract information about the names
-defined in each context of the module and associate any docstrings with the
-names.  The code to perform this work is not complicated, but bears some
-explanation.
-
-The public interface to the classes is straightforward and should probably be
-somewhat more flexible.  Each "major" block of the module is described by an
-object providing several methods for inquiry and a constructor which accepts at
-least the subtree of the complete parse tree which it represents.  The
-:class:`ModuleInfo` constructor accepts an optional *name* parameter since it
-cannot otherwise determine the name of the module.
-
-The public classes include :class:`ClassInfo`, :class:`FunctionInfo`, and
-:class:`ModuleInfo`.  All objects provide the methods :meth:`get_name`,
-:meth:`get_docstring`, :meth:`get_class_names`, and :meth:`get_class_info`.  The
-:class:`ClassInfo` objects support :meth:`get_method_names` and
-:meth:`get_method_info` while the other classes provide
-:meth:`get_function_names` and :meth:`get_function_info`.
-
-Within each of the forms of code block that the public classes represent, most
-of the required information is in the same form and is accessed in the same way,
-with classes having the distinction that functions defined at the top level are
-referred to as "methods." Since the difference in nomenclature reflects a real
-semantic distinction from functions defined outside of a class, the
-implementation needs to maintain the distinction. Hence, most of the
-functionality of the public classes can be implemented in a common base class,
-:class:`SuiteInfoBase`, with the accessors for function and method information
-provided elsewhere. Note that there is only one class which represents function
-and method information; this parallels the use of the :keyword:`def` statement
-to define both types of elements.
-
-Most of the accessor functions are declared in :class:`SuiteInfoBase` and do not
-need to be overridden by subclasses.  More importantly, the extraction of most
-information from a parse tree is handled through a method called by the
-:class:`SuiteInfoBase` constructor.  The example code for most of the classes is
-clear when read alongside the formal grammar, but the method which recursively
-creates new information objects requires further examination.  Here is the
-relevant part of the :class:`SuiteInfoBase` definition from :file:`example.py`::
-
-   class SuiteInfoBase:
-       _docstring = ''
-       _name = ''
-
-       def __init__(self, tree = None):
-           self._class_info = {}
-           self._function_info = {}
-           if tree:
-               self._extract_info(tree)
-
-       def _extract_info(self, tree):
-           # extract docstring
-           if len(tree) == 2:
-               found, vars = match(DOCSTRING_STMT_PATTERN[1], tree[1])
-           else:
-               found, vars = match(DOCSTRING_STMT_PATTERN, tree[3])
-           if found:
-               self._docstring = eval(vars['docstring'])
-           # discover inner definitions
-           for node in tree[1:]:
-               found, vars = match(COMPOUND_STMT_PATTERN, node)
-               if found:
-                   cstmt = vars['compound']
-                   if cstmt[0] == symbol.funcdef:
-                       name = cstmt[2][1]
-                       self._function_info[name] = FunctionInfo(cstmt)
-                   elif cstmt[0] == symbol.classdef:
-                       name = cstmt[2][1]
-                       self._class_info[name] = ClassInfo(cstmt)
-
-After initializing some internal state, the constructor calls the
-:meth:`_extract_info` method.  This method performs the bulk of the information
-extraction which takes place in the entire example.  The extraction has two
-distinct phases: the location of the docstring for the parse tree passed in, and
-the discovery of additional definitions within the code block represented by the
-parse tree.
-
-The initial :keyword:`if` test determines whether the nested suite is of the
-"short form" or the "long form."  The short form is used when the code block is
-on the same line as the definition of the code block, as in ::
-
-   def square(x): "Square an argument."; return x ** 2
-
-while the long form uses an indented block and allows nested definitions::
-
-   def make_power(exp):
-       "Make a function that raises an argument to the exponent `exp`."
-       def raiser(x, y=exp):
-           return x ** y
-       return raiser
-
-When the short form is used, the code block may contain a docstring as the
-first, and possibly only, :const:`small_stmt` element.  The extraction of such a
-docstring is slightly different and requires only a portion of the complete
-pattern used in the more common case.  As implemented, the docstring will only
-be found if there is only one :const:`small_stmt` node in the
-:const:`simple_stmt` node. Since most functions and methods which use the short
-form do not provide a docstring, this may be considered sufficient.  The
-extraction of the docstring proceeds using the :func:`match` function as
-described above, and the value of the docstring is stored as an attribute of the
-:class:`SuiteInfoBase` object.
-
-After docstring extraction, a simple definition discovery algorithm operates on
-the :const:`stmt` nodes of the :const:`suite` node.  The special case of the
-short form is not tested; since there are no :const:`stmt` nodes in the short
-form, the algorithm will silently skip the single :const:`simple_stmt` node and
-correctly not discover any nested definitions.
-
-Each statement in the code block is categorized as a class definition, function
-or method definition, or something else.  For the definition statements, the
-name of the element defined is extracted and a representation object appropriate
-to the definition is created with the defining subtree passed as an argument to
-the constructor.  The representation objects are stored in instance variables
-and may be retrieved by name using the appropriate accessor methods.
-
-The public classes provide any accessors required which are more specific than
-those provided by the :class:`SuiteInfoBase` class, but the real extraction
-algorithm remains common to all forms of code blocks.  A high-level function can
-be used to extract the complete set of information from a source file.  (See
-file :file:`example.py`.) ::
-
-   def get_docs(fileName):
-       import os
-       import parser
-
-       source = open(fileName).read()
-       basename = os.path.basename(os.path.splitext(fileName)[0])
-       st = parser.suite(source)
-       return ModuleInfo(st.totuple(), basename)
-
-This provides an easy-to-use interface to the documentation of a module.  If
-information is required which is not extracted by the code of this example, the
-code may be extended at clearly defined points to provide additional
-capabilities.
-
diff --git a/Doc/library/pickle.rst b/Doc/library/pickle.rst
index 5466a7e..963468d 100644
--- a/Doc/library/pickle.rst
+++ b/Doc/library/pickle.rst
@@ -25,6 +25,12 @@
 This documentation describes both the :mod:`pickle` module and the
 :mod:`cPickle` module.
 
+.. warning::
+
+   The :mod:`pickle` module is not intended to be secure against erroneous or
+   maliciously constructed data.  Never unpickle data received from an untrusted
+   or unauthenticated source.
+
 
 Relationship to other Python modules
 ------------------------------------
@@ -74,12 +80,6 @@
   The :mod:`pickle` serialization format is guaranteed to be backwards compatible
   across Python releases.
 
-.. warning::
-
-   The :mod:`pickle` module is not intended to be secure against erroneous or
-   maliciously constructed data.  Never unpickle data received from an untrusted
-   or unauthenticated source.
-
 Note that serialization is a more primitive notion than persistence; although
 :mod:`pickle` reads and writes file objects, it does not handle the issue of
 naming persistent objects, nor the (even more complicated) issue of concurrent
diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst
index d99d184..decb12d 100644
--- a/Doc/library/stdtypes.rst
+++ b/Doc/library/stdtypes.rst
@@ -1944,15 +1944,12 @@
    values are added as items to the dictionary. If a key is specified both in the
    positional argument and as a keyword argument, the value associated with the
    keyword is retained in the dictionary. For example, these all return a
-   dictionary equal to ``{"one": 2, "two": 3}``:
+   dictionary equal to ``{"one": 1, "two": 2}``:
 
-   * ``dict(one=2, two=3)``
-
-   * ``dict({'one': 2, 'two': 3})``
-
-   * ``dict(zip(('one', 'two'), (2, 3)))``
-
-   * ``dict([['two', 3], ['one', 2]])``
+   * ``dict(one=1, two=2)``
+   * ``dict({'one': 1, 'two': 2})``
+   * ``dict(zip(('one', 'two'), (1, 2)))``
+   * ``dict([['two', 2], ['one', 1]])``
 
    The first example only works for keys that are valid Python
    identifiers; the others work with any valid keys.
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
index 3997627..e812b85 100644
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -53,6 +53,13 @@
    ``modules.keys()`` only lists the imported modules.)
 
 
+.. function:: call_tracing(func, args)
+
+   Call ``func(*args)``, while tracing is enabled.  The tracing state is saved,
+   and restored afterwards.  This is intended to be called from a debugger from
+   a checkpoint, to recursively debug some other code.
+
+
 .. data:: copyright
 
    A string containing the copyright pertaining to the Python interpreter.
@@ -219,19 +226,25 @@
 
    Exit from Python.  This is implemented by raising the :exc:`SystemExit`
    exception, so cleanup actions specified by finally clauses of :keyword:`try`
-   statements are honored, and it is possible to intercept the exit attempt at an
-   outer level.  The optional argument *arg* can be an integer giving the exit
-   status (defaulting to zero), or another type of object.  If it is an integer,
-   zero is considered "successful termination" and any nonzero value is considered
-   "abnormal termination" by shells and the like.  Most systems require it to be in
-   the range 0-127, and produce undefined results otherwise.  Some systems have a
-   convention for assigning specific meanings to specific exit codes, but these are
-   generally underdeveloped; Unix programs generally use 2 for command line syntax
-   errors and 1 for all other kind of errors.  If another type of object is passed,
-   ``None`` is equivalent to passing zero, and any other object is printed to
-   ``sys.stderr`` and results in an exit code of 1.  In particular,
-   ``sys.exit("some error message")`` is a quick way to exit a program when an
-   error occurs.
+   statements are honored, and it is possible to intercept the exit attempt at
+   an outer level.
+
+   The optional argument *arg* can be an integer giving the exit status
+   (defaulting to zero), or another type of object.  If it is an integer, zero
+   is considered "successful termination" and any nonzero value is considered
+   "abnormal termination" by shells and the like.  Most systems require it to be
+   in the range 0-127, and produce undefined results otherwise.  Some systems
+   have a convention for assigning specific meanings to specific exit codes, but
+   these are generally underdeveloped; Unix programs generally use 2 for command
+   line syntax errors and 1 for all other kind of errors.  If another type of
+   object is passed, ``None`` is equivalent to passing zero, and any other
+   object is printed to :data:`stderr` and results in an exit code of 1.  In
+   particular, ``sys.exit("some error message")`` is a quick way to exit a
+   program when an error occurs.
+
+   Since :func:`exit` ultimately "only" raises an exception, it will only exit
+   the process when called from the main thread, and the exception is not
+   intercepted.
 
 
 .. data:: exitfunc