Fix a few doc errors, mostly undefined keywords.

5 files changed, 24 insertions, 25 deletions

diff --git a/Doc/whatsnew/2.0.rst b/Doc/whatsnew/2.0.rst
index 3bb12b6..850e57d 100644
--- a/Doc/whatsnew/2.0.rst
+++ b/Doc/whatsnew/2.0.rst
@@ -189,7 +189,7 @@ support Unicode:
   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()``,
+* The ``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
@@ -515,11 +515,11 @@ functions::
        # kw is a dictionary of keyword args
        ...
 
-The :keyword:`print` statement can now have its output directed to a file-like
-object by following the :keyword:`print` with  ``>> file``, similar to the
+The ``print`` statement can now have its output directed to a file-like
+object by following the ``print`` with  ``>> file``, similar to the
 redirection operator in Unix shells. Previously you'd either have to use the
 :meth:`write` method of the file-like object, which lacks the convenience and
-simplicity of :keyword:`print`, or you could assign a new value to
+simplicity of ``print``, or you could assign a new value to
 ``sys.stdout`` and then restore the old value.  For sending output to standard
 error, it's much easier to write this::
 
@@ -581,7 +581,7 @@ 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
+exception on the ``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
diff --git a/Doc/whatsnew/2.1.rst b/Doc/whatsnew/2.1.rst
index 7f40521..117af10 100644
--- a/Doc/whatsnew/2.1.rst
+++ b/Doc/whatsnew/2.1.rst
@@ -81,13 +81,13 @@ though, since such code would have been pretty confusing to read in the first
 place.
 
 One side effect of the change is that the ``from module import *`` and
-:keyword:`exec` statements have been made illegal inside a function scope under
+``exec`` statements have been made illegal inside a function scope under
 certain conditions.  The Python reference manual has said all along that ``from
 module import *`` is only legal at the top level of a module, but the CPython
 interpreter has never enforced this before.  As part of the implementation of
 nested scopes, the compiler which turns Python source into bytecodes has to
 generate different code to access variables in a containing scope.  ``from
-module import *`` and :keyword:`exec` make it impossible for the compiler to
+module import *`` and ``exec`` make it impossible for the compiler to
 figure this out, because they add names to the local namespace that are
 unknowable at compile time. Therefore, if a function contains function
 definitions or :keyword:`lambda` expressions with free variables, the compiler
@@ -102,11 +102,11 @@ To make the preceding explanation a bit clearer, here's an example::
        def g():
            return x
 
-Line 4 containing the :keyword:`exec` statement is a syntax error, since
-:keyword:`exec` would define a new local variable named ``x`` whose value should
+Line 4 containing the ``exec`` statement is a syntax error, since
+``exec`` would define a new local variable named ``x`` whose value should
 be accessed by :func:`g`.
 
-This shouldn't be much of a limitation, since :keyword:`exec` is rarely used in
+This shouldn't be much of a limitation, since ``exec`` is rarely used in
 most Python code (and when it is used, it's often a sign of a poor design
 anyway).
 
diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 412c1d0..1db1ee7 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -892,13 +892,13 @@ though, since such code would have been pretty confusing to read in the first
 place.
 
 One side effect of the change is that the ``from module import *`` and
-:keyword:`exec` statements have been made illegal inside a function scope under
+``exec`` statements have been made illegal inside a function scope under
 certain conditions.  The Python reference manual has said all along that ``from
 module import *`` is only legal at the top level of a module, but the CPython
 interpreter has never enforced this before.  As part of the implementation of
 nested scopes, the compiler which turns Python source into bytecodes has to
 generate different code to access variables in a containing scope.  ``from
-module import *`` and :keyword:`exec` make it impossible for the compiler to
+module import *`` and ``exec`` make it impossible for the compiler to
 figure this out, because they add names to the local namespace that are
 unknowable at compile time. Therefore, if a function contains function
 definitions or :keyword:`lambda` expressions with free variables, the compiler
@@ -913,11 +913,11 @@ To make the preceding explanation a bit clearer, here's an example::
        def g():
            return x
 
-Line 4 containing the :keyword:`exec` statement is a syntax error, since
-:keyword:`exec` would define a new local variable named ``x`` whose value should
+Line 4 containing the ``exec`` statement is a syntax error, since
+``exec`` would define a new local variable named ``x`` whose value should
 be accessed by :func:`g`.
 
-This shouldn't be much of a limitation, since :keyword:`exec` is rarely used in
+This shouldn't be much of a limitation, since ``exec`` is rarely used in
 most Python code (and when it is used, it's often a sign of a poor design
 anyway).
 
diff --git a/Doc/whatsnew/2.4.rst b/Doc/whatsnew/2.4.rst
index 3a12a79..c52b5fb 100644
--- a/Doc/whatsnew/2.4.rst
+++ b/Doc/whatsnew/2.4.rst
@@ -896,7 +896,7 @@ Here are all of the changes that Python 2.4 makes to the core Python language.
   (Contributed by Nick Coghlan.)
 
 * The :func:`eval(expr, globals, locals)` and :func:`execfile(filename, globals,
-  locals)` functions and the :keyword:`exec` statement now accept any mapping type
+  locals)` functions and the ``exec`` statement now accept any mapping type
   for the *locals* parameter.  Previously this had to be a regular Python
   dictionary.  (Contributed by Raymond Hettinger.)
 
diff --git a/Doc/whatsnew/3.0.rst b/Doc/whatsnew/3.0.rst
index b7f7233..852f811 100644
--- a/Doc/whatsnew/3.0.rst
+++ b/Doc/whatsnew/3.0.rst
@@ -96,9 +96,9 @@ up if you're used to Python 2.5.
 Print Is A Function
 -------------------
 
-The :keyword:`print` statement has been replaced with a :func:`print`
+The ``print`` statement has been replaced with a :func:`print`
 function, with keyword arguments to replace most of the special syntax
-of the old :keyword:`print` statement (:pep:`3105`).  Examples::
+of the old ``print`` statement (:pep:`3105`).  Examples::
 
   Old: print "The answer is", 2*2
   New: print("The answer is", 2*2)
@@ -126,7 +126,7 @@ which produces::
 Note:
 
 * The :func:`print` function doesn't support the "softspace" feature of
-  the old :keyword:`print` statement.  For example, in Python 2.x,
+  the old ``print`` statement.  For example, in Python 2.x,
   ``print "A\n", "B"`` would write ``"A\nB\n"``; but in Python 3.0,
   ``print("A\n", "B")`` writes ``"A\n B\n"``.
 
@@ -135,7 +135,7 @@ Note:
   ``print(x)`` instead!
 
 * When using the ``2to3`` source-to-source conversion tool, all
-  :keyword:`print` statements are automatically converted to
+  ``print`` statements are automatically converted to
   :func:`print` function calls, so this is mostly a non-issue for
   larger projects.
 
@@ -178,7 +178,7 @@ Python 3.0 has simplified the rules for ordering comparisons:
   meaningful natural ordering.  Thus, expressions like ``1 < ''``, ``0
   > None`` or ``len <= len`` are no longer valid, and e.g. ``None <
   None`` raises :exc:`TypeError` instead of returning
-  :keyword:`False`.  A corollary is that sorting a heterogeneous list
+  ``False``.  A corollary is that sorting a heterogeneous list
   no longer makes sense -- all the elements must be comparable to each
   other.  Note that this does not apply to the ``==`` and ``!=``
   operators: objects of different incomparable types always compare
@@ -397,9 +397,8 @@ Changed Syntax
 * :keyword:`as` and :keyword:`with` are now reserved words.  (Since
   2.6, actually.)
 
-* :keyword:`True`, :keyword:`False`, and :keyword:`None` are reserved
-  words.  (2.6 partially enforced the restrictions on :keyword:`None`
-  already.)
+* ``True``, ``False``, and ``None`` are reserved words.  (2.6 partially enforced
+  the restrictions on ``None`` already.)
 
 * Change from :keyword:`except` *exc*, *var* to
   :keyword:`except` *exc* :keyword:`as` *var*.  See :pep:`3110`.
@@ -906,7 +905,7 @@ best strategy is the following:
 
 It is not recommended to try to write source code that runs unchanged
 under both Python 2.6 and 3.0; you'd have to use a very contorted
-coding style, e.g. avoiding :keyword:`print` statements, metaclasses,
+coding style, e.g. avoiding ``print`` statements, metaclasses,
 and much more.  If you are maintaining a library that needs to support
 both Python 2.6 and Python 3.0, the best approach is to modify step 3
 above by editing the 2.6 version of the source code and running the