Miscellaneous fixes and formatting enhancements. (#238)

pep-0202.txt

@@ -30,7 +30,7 @@ Rationale
 =========
 
 List comprehensions provide a more concise way to create lists in situations
-where map() and filter() and/or nested loops would currently be used.
+where ``map()`` and ``filter()`` and/or nested loops would currently be used.
 
 
 Examples

pep-0204.txt

@@ -50,11 +50,11 @@ above construct.
 For these instances, and others where a range of numbers is
 desired, Python provides the ``range`` builtin function, which
 creates a list of numbers.  The ``range`` function takes three
-arguments, ``start``, ``end`` and ``step``.  ``start`` and ``step`` are
+arguments, *start*, *end* and *step*.  *start* and *step* are
 optional, and default to 0 and 1, respectively.
 
 The ``range`` function creates a list of numbers, starting at
-``start``, with a step of ``step``, up to, but not including ``end``, so
+*start*, with a step of *step*, up to, but not including *end*, so
 that ``range(10)`` produces a list that has exactly 10 items, the
 numbers 0 through 9.
 
@@ -109,19 +109,19 @@ the original sequence.  This is done using a "range notation"::
    ['c', 'd']
 
 This range notation consists of zero, one or two indices separated
-by a colon.  The first index is the ``start`` index, the second the
-``end``.  When either is left out, they default to respectively the
+by a colon.  The first index is the *start* index, the second the
+*end*.  When either is left out, they default to respectively the
 start and the end of the sequence.
 
 There is also an extended range notation, which incorporates
-``step`` as well.  Though this notation is not currently supported
+*step* as well.  Though this notation is not currently supported
 by most builtin types, if it were, it would work as follows::
 
    >>> l[1:4:2]
    ['b', 'd']
 
 The third "argument" to the slice syntax is exactly the same as
-the ``step`` argument to ``range()``.  The underlying mechanisms of the
+the *step* argument to ``range()``.  The underlying mechanisms of the
 standard, and these extended slices, are sufficiently different
 and inconsistent that many classes and extensions outside of
 mathematical packages do not implement support for the extended
@@ -160,9 +160,9 @@ range literals::
    [5, 4, 3, 2]
 
 There is one minor difference between range literals and the slice
-syntax: though it is possible to omit all of ``start``, ``end`` and
-``step`` in slices, it does not make sense to omit ``end`` in range
-literals.  In slices, ``end`` would default to the end of the list,
+syntax: though it is possible to omit all of *start*, *end* and
+*step* in slices, it does not make sense to omit *end* in range
+literals.  In slices, *end* would default to the end of the list,
 but this has no meaning in range literals.
 
 
@@ -178,7 +178,7 @@ The use of a new bytecode is necessary to be able to build ranges
 based on other calculations, whose outcome is not known at compile
 time.
 
-The code introduces two new functions to listobject.c, which are
+The code introduces two new functions to ``listobject.c``, which are
 currently hovering between private functions and full-fledged API
 calls.
 
@@ -189,8 +189,8 @@ returning NULL if an error occurs.  Its prototype is::
 
 ``PyList_GetLenOfRange()`` is a helper function used to determine the
 length of a range.  Previously, it was a static function in
-bltinmodule.c, but is now necessary in both listobject.c and
-bltinmodule.c (for ``xrange``).  It is made non-static solely to avoid
+``bltinmodule.c``, but is now necessary in both ``listobject.c`` and
+``bltinmodule.c`` (for ``xrange``).  It is made non-static solely to avoid
 code duplication.  Its prototype is::
 
     long PyList_GetLenOfRange(long start, long end, long step)
@@ -199,7 +199,7 @@ code duplication.  Its prototype is::
 Open issues
 ===========
 
-- One possible solution to the discrepancy of requiring the ``end``
+- One possible solution to the discrepancy of requiring the *end*
   argument in range literals is to allow the range syntax to
   create a "generator", rather than a list, such as the ``xrange``
   builtin function does.  However, a generator would not be a

pep-0206.txt

@@ -28,10 +28,10 @@ start in many projects.
 
 However, the standard library modules aren't always the best
 choices for a job.  Some library modules were quick hacks
-(e.g. calendar, commands), some were designed poorly and are now
-near-impossible to fix (cgi), and some have been rendered obsolete
-by other, more complete modules (binascii offers the same features
-as the binhex, uu, base64 modules).  This PEP describes a list of
+(e.g. ``calendar``, ``commands``), some were designed poorly and are now
+near-impossible to fix (``cgi``), and some have been rendered obsolete
+by other, more complete modules (``binascii`` offers the same features
+as the ``binhex``, ``uu``, ``base64`` modules).  This PEP describes a list of
 third-party modules that make Python more competitive for various
 application domains, forming the Python Advanced Library.
 

pep-0211.txt

@@ -64,8 +64,8 @@ operators for matrix solution and other operations, Prof. James
 Rawlings replied [3]_:
 
     I DON'T think it's a must have, and I do a lot of matrix
-    inversion. I cannot remember if its A\b or b\A so I always
-    write inv(A)*b instead. I recommend dropping \.
+    inversion. I cannot remember if its ``A\b`` or ``b\A`` so I always
+    write ``inv(A)*b`` instead. I recommend dropping ``\``.
 
 Based on this discussion, and feedback from students at the US
 national laboratories and elsewhere, we recommended adding only

pep-0215.txt

@@ -58,7 +58,7 @@ or with ``unicode()`` if it is a Unicode string.
     - an expression enclosed in square brackets, or
     - an argument list enclosed in parentheses
     (This is exactly the pattern expressed in the Python grammar
-    by "``NAME`` trailer*", using the definitions in Grammar/Grammar.)
+    by "``NAME trailer*``", using the definitions in ``Grammar/Grammar``.)
 
 2.  Any complete Python expression enclosed in curly braces.
 
@@ -69,7 +69,7 @@ Examples
 ========
 
 Here is an example of an interactive session exhibiting the
-expected behaviour of this feature::
+expected behaviour of this feature. ::
 
    >>> a, b = 5, 6
    >>> print $'a = $a, b = $b'
@@ -127,18 +127,18 @@ Implementation
 ==============
 
 The ``Itpl`` module at [1]_ provides a
-prototype of this feature.  It uses the tokenize module to find
+prototype of this feature.  It uses the ``tokenize`` module to find
 the end of an expression to be interpolated, then calls ``eval()``
 on the expression each time a value is needed.  In the prototype,
 the expression is parsed and compiled again each time it is
 evaluated.
 
 As an optimization, interpolated strings could be compiled
-directly into the corresponding bytecode; that is::
+directly into the corresponding bytecode; that is, ::
 
    $'a = $a, b = $b'
 
-could be compiled as though it were the expression::
+could be compiled as though it were the expression ::
 
    ('a = ' + str(a) + ', b = ' + str(b))
 

pep-0218.txt

@@ -40,8 +40,8 @@ not...)
 Programmers are often told that they can implement sets as
 dictionaries with "don't care" values.  Items can be added to
 these "sets" by assigning the "don't care" value to them;
-membership can be tested using "dict.has_key"; and items can be
-deleted using "del".  However, the other main operations on sets
+membership can be tested using ``dict.has_key``; and items can be
+deleted using ``del``.  However, the other main operations on sets
 (union, intersection, and difference) are not directly supported
 by this representation, since their meaning is ambiguous for
 dictionaries containing key/value pairs.
@@ -65,22 +65,22 @@ will step through the elements of S in arbitrary order, while::
     set(x**2 for x in S)
 
 will produce a set containing the squares of all elements in S,
-Membership will be tested using "in" and "not in", and basic set
+Membership will be tested using ``in`` and ``not in``, and basic set
 operations will be implemented by a mixture of overloaded
 operators:
 
-=========  =============================
-\|         union
-&          intersection
-^          symmetric difference
-\-          asymmetric difference
-== !=      equality and inequality tests
-< <= >= >  subset and superset tests
-=========  =============================
+=============  =============================
+``|``          union
+``&``          intersection
+``^``          symmetric difference
+``-``          asymmetric difference
+``== !=``      equality and inequality tests
+``< <= >= >``  subset and superset tests
+=============  =============================
 
 and methods:
 
-==================  ============================================
+==================  =============================================
 ``S.add(x)``        Add "x" to the set.
 
 ``S.update(s)``     Add all elements of sequence "s" to the set.
@@ -93,8 +93,8 @@ and methods:
                     do nothing if it is not.
 
 ``S.pop()``         Remove and return an arbitrary element,
-                    raising a LookupError if the element is not
-                    present.
+                    raising a ``LookupError`` if the element is
+                    not present.
 
 ``S.clear()``       Remove all elements from this set.
 
@@ -103,7 +103,7 @@ and methods:
 ``s.issuperset()``  Check for a superset relationship.
 
 ``s.issubset()``    Check for a subset relationship.
-==================  ============================================
+==================  =============================================
 
 and two new built-in conversion functions:
 
@@ -117,23 +117,23 @@ and two new built-in conversion functions:
 
 Notes:
 
-1. We propose using the bitwise operators "\|\&" for intersection
-   and union.  While "+" for union would be intuitive, "\*" for
+1. We propose using the bitwise operators "``|&``" for intersection
+   and union.  While "``+``" for union would be intuitive, "``*``" for
    intersection is not (very few of the people asked guessed what
    it did correctly).
 
-2. We considered using "+" to add elements to a set, rather than
-   "add".  However, Guido van Rossum pointed out that "+" is
-   symmetric for other built-in types (although "\*" is not).  Use
+2. We considered using "``+``" to add elements to a set, rather than
+   "add".  However, Guido van Rossum pointed out that "``+``" is
+   symmetric for other built-in types (although "``*``" is not).  Use
    of "add" will also avoid confusion between that operation and
    set union.
 
 
 Set Notation
 ============
 
-The PEP originally proposed {1,2,3} as the set notation and {-} for
-the empty set.  Experience with Python 2.3's sets.py showed that
+The PEP originally proposed ``{1,2,3}`` as the set notation and ``{-}`` for
+the empty set.  Experience with Python 2.3's ``sets.py`` showed that
 the notation was not necessary.  Also, there was some risk of making
 dictionaries less instantly recognizable.
 
@@ -156,7 +156,7 @@ types were introduced in Python 2.4.  The improvements are:
 * Better hash algorithm for frozensets
 * More compact pickle format (storing only an element list
   instead of a dictionary of key:value pairs where the value
-  is always True).
+  is always ``True``).
 * Use a ``__reduce__`` function so that deep copying is automatic.
 * The BaseSet concept was eliminated.
 * The ``union_update()`` method became just ``update()``.
@@ -196,9 +196,9 @@ to be immutable, this would preclude sets of sets (which are
 widely used in graph algorithms and other applications).
 
 Earlier drafts of PEP 218 had only a single set type, but the
-sets.py implementation in Python 2.3 has two, Set and
+``sets.py`` implementation in Python 2.3 has two, Set and
 ImmutableSet.  For Python 2.4, the new built-in types were named
-set and frozenset which are slightly less cumbersome.
+``set`` and ``frozenset`` which are slightly less cumbersome.
 
 There are two classes implemented in the "sets" module.  Instances
 of the Set class can be modified by the addition or removal of

pep-0221.txt

@@ -55,17 +55,17 @@ more advanced parsers/tokenizers, however, this should not be a
 problem.
 
 A slightly special case exists for importing sub-modules.  The
-statement::
+statement ::
 
     import os.path
 
 stores the module ``os`` locally as ``os``, so that the imported
-submodule ``path`` is accessible as ``os.path``.  As a result::
+submodule ``path`` is accessible as ``os.path``.  As a result, ::
 
     import os.path as p
 
 stores ``os.path``, not ``os``, in ``p``.  This makes it effectively the
-same as::
+same as ::
 
     from os import path as p
 

pep-0222.txt

@@ -42,11 +42,11 @@ And even if we did, that would mean creating yet another object
 with its ``__init__`` call and associated overhead.
 
 cgi.py: Currently, query data with no ``=`` are ignored.  Even if
-keep_blank_values is set, queries like ``...?value=&...`` are
+``keep_blank_values`` is set, queries like ``...?value=&...`` are
 returned with blank values but queries like ``...?value&...`` are
 completely lost.  It would be great if such data were made
 available through the ``FieldStorage`` interface, either as entries
-with None as values, or in a separate list.
+with ``None`` as values, or in a separate list.
 
 Utility function: build a query string from a list of 2-tuples
 

pep-0223.txt

@@ -25,12 +25,12 @@ to existing code.
 Syntax
 ======
 
-The syntax of ``\x`` escapes, in all flavors of non-raw strings, becomes::
+The syntax of ``\x`` escapes, in all flavors of non-raw strings, becomes ::
 
    \xhh
 
 where h is a hex digit (0-9, a-f, A-F).  The exact syntax in 1.5.2 is
-not clearly specified in the Reference Manual; it says::
+not clearly specified in the Reference Manual; it says ::
 
    \xhh...
 
@@ -44,11 +44,11 @@ whether the Reference Manual intended either of the 1-digit or
 Semantics
 =========
 
-In an 8-bit non-raw string::
+In an 8-bit non-raw string, ::
 
    \xij
 
-expands to the character::
+expands to the character ::
 
    chr(int(ij, 16))
 
@@ -59,15 +59,15 @@ In a Unicode string,
 
    \xij
 
-acts the same as::
+acts the same as ::
 
    \u00ij
 
 i.e. it expands to the obvious Latin-1 character from the initial
 segment of the Unicode space.
 
 An ``\x`` not followed by at least two hex digits is a compile-time error,
-specifically ``ValueError`` in 8-bit strings, and UnicodeError (a subclass
+specifically ``ValueError`` in 8-bit strings, and ``UnicodeError`` (a subclass
 of ``ValueError``) in Unicode strings.  Note that if an ``\x`` is followed by
 more than two hex digits, only the first two are "consumed".  In 1.6
 and before all but the *last* two were silently ignored.
@@ -126,7 +126,7 @@ than 2 hex digits following -- it's clearly more Pythonic to insist on
 
 When Unicode strings were introduced to Python, ``\x`` was generalized so
 as to ignore all but the last *four* hex digits in Unicode strings.
-This caused a technical difficulty for the new regular expression engine::
+This caused a technical difficulty for the new regular expression engine:
 SRE tries very hard to allow mixing 8-bit and Unicode patterns and
 strings in intuitive ways, and it no longer had any way to guess what,
 for example, ``r"\x123456"`` should mean as a pattern:  is it asking to match
@@ -192,10 +192,10 @@ Believed to be none.  The candidates for breakage would mostly be
 parsing tools, but the author knows of none that worry about the
 internal structure of Python strings beyond the approximation "when
 there's a backslash, swallow the next character".  Tim Peters checked
-python-mode.el, the std tokenize.py and pyclbr.py, and the IDLE syntax
+``python-mode.el``, the std ``tokenize.py`` and ``pyclbr.py``, and the IDLE syntax
 coloring subsystem, and believes there's no need to change any of
-them.  Tools like tabnanny.py and checkappend.py inherit their immunity
-from tokenize.py.
+them.  Tools like ``tabnanny.py`` and ``checkappend.py`` inherit their immunity
+from ``tokenize.py``.
 
 
 Reference Implementation

pep-0224.txt

@@ -191,7 +191,7 @@ Early comments on the PEP from Guido:
 
     2. I don't like the access method either (``__doc_<attrname>__``).
 
-The author's reply
+The author's reply:
 
     ::