PEP 436: fix markup and make it consistent.

pep-0436.txt

@@ -49,24 +49,24 @@ But over the years the ``PyArg_Parse`` interface has been extended
 in numerous ways.  The modern API is complex, to the point that it
 is somewhat painful to use.  Consider:
 
-  * There are now forty different "format units"; a few are even three
+* There are now forty different "format units"; a few are even three
   characters long.  This makes it difficult for the programmer to
   understand what the format string says--or even perhaps to parse
   it--without constantly cross-indexing it with the documentation.
-  * There are also six meta-format units that may be buried in the
+* There are also six meta-format units that may be buried in the
   format string.  (They are: ``"()|$:;"``.)
-  * The more format units are added, the less likely it is the
+* The more format units are added, the less likely it is the
   implementer can pick an easy-to-use mnemonic for the format unit,
   because the character of choice is probably already in use.  In
   other words, the more format units we have, the more obtuse the
   format units become.
-  * Several format units are nearly identical to others, having only
+* Several format units are nearly identical to others, having only
   subtle differences.  This makes understanding the exact semantics
   of the format string even harder, and can make it difficult to
   figure out exactly which format unit you want.
-  * The docstring is specified as a static C string, making it mildly
+* The docstring is specified as a static C string, making it mildly
   bothersome to read and edit since it must obey C string quoting rules.
-  * When adding a new parameter to a function using
+* When adding a new parameter to a function using
   ``PyArg_ParseTupleAndKeywords()``, it's necessary to touch six
   different places in the code: [4]_
 
@@ -82,7 +82,7 @@ is somewhat painful to use.  Consider:
   * Adding the parameter to the prototype in the docstring.
   * Documenting the parameter in the docstring.
 
-  * There is currently no mechanism for builtin functions to provide
+* There is currently no mechanism for builtin functions to provide
   their "signature" information (see ``inspect.getfullargspec`` and
   ``inspect.Signature``).  Adding this information using a mechanism
   similar to the existing ``PyArg_Parse`` functions would require
@@ -91,16 +91,16 @@ is somewhat painful to use.  Consider:
 The goal of Argument Clinic is to replace this API with a mechanism
 inheriting none of these downsides:
 
-  * You need specify each parameter only once.
-  * All information about a parameter is kept together in one place.
-  * For each parameter, you specify a conversion function; Argument
+* You need specify each parameter only once.
+* All information about a parameter is kept together in one place.
+* For each parameter, you specify a conversion function; Argument
   Clinic handles the translation from Python value into C value for
   you.
-  * Argument Clinic also allows for fine-tuning of argument processing
+* Argument Clinic also allows for fine-tuning of argument processing
   behavior with parameterized conversion functions.
-  * Docstrings are written in plain text.  Function docstrings are
+* Docstrings are written in plain text.  Function docstrings are
   required; per-parameter docstrings are encouraged.
-  * From this, Argument Clinic generates for you all the mundane,
+* From this, Argument Clinic generates for you all the mundane,
   repetitious code and data structures CPython needs internally.
   Once you've specified the interface, the next step is simply to
   write your implementation using native C types.  Every detail of
@@ -121,10 +121,10 @@ interpreter.
 
 Future goals of Argument Clinic include:
 
-  * providing signature information for builtins,
-  * enabling alternative implementations of Python to create
+* providing signature information for builtins,
+* enabling alternative implementations of Python to create
   automated library compatibility tests, and
-  * speeding up argument parsing with improvements to the
+* speeding up argument parsing with improvements to the
   generated code.
 
 
@@ -162,9 +162,7 @@ To give some flavor of the proposed DSL syntax, here are some sample Clinic
 code blocks.  This first block reflects the normally preferred style, including
 blank lines between parameters and per-argument docstrings.
 It also includes a user-defined converter (``path_t``) created
-locally 
-
-::
+locally::
 
    /*[clinic]
    os.stat as os_stat_fn -> stat result
@@ -275,15 +273,11 @@ Module and Class Declarations
 -----------------------------
 
 When a C file implements a module or class, this should be declared to
-Clinic.  The syntax is simple:
-
-::
+Clinic.  The syntax is simple::
 
    module module_name
 
-or
-
-::
+or ::
 
    class module_name.class_name
 
@@ -297,9 +291,7 @@ from the top-level module.  Nested modules and classes are supported.
 Function Declaration
 --------------------
 
-The full form of the function declaration is as follows:
-
-::
+The full form of the function declaration is as follows::
 
    dotted.name [ as legal_c_id ] [ -> return_annotation ]
 
@@ -323,9 +315,7 @@ a *return converter*.
 Parameter Declaration
 ---------------------
 
-The full form of the parameter declaration line as as follows:
-
-::
+The full form of the parameter declaration line as as follows::
 
    name: converter [ (parameter=value [, parameter2=value2]) ] [ = default]
 
@@ -377,9 +367,7 @@ For convenience's sake in converting existing code to Argument Clinic,
 Clinic provides a set of legacy converters that match ``PyArg_ParseTuple``
 format units.  They are specified as a C string containing the format
 unit.  For example, to specify a parameter "foo" as taking a Python
-"int" and emitting a C int, you could specify:
-
-::
+"int" and emitting a C int, you could specify::
 
    foo : "i"
 
@@ -554,9 +542,7 @@ Argument Clinic also permits "directives" in Clinic code blocks.
 Directives are similar to *pragmas* in C; they are statements
 that modify Argument Clinic's behavior.
 
-The format of a directive is as follows:
-
-::
+The format of a directive is as follows::
 
    directive_name [argument [second_argument [ ... ]]]
 
@@ -581,9 +567,7 @@ Python Code
 
 Argument Clinic also permits embedding Python code inside C files,
 which is executed in-place when Argument Clinic processes the file.
-Embedded code looks like this:
-
-::
+Embedded code looks like this::
 
    /*[python]
 
@@ -610,14 +594,14 @@ after the section of Clinic code.  For "python" sections, the output
 is everything printed using ``builtins.print``.  For "clinic"
 sections, the output is valid C code, including:
 
-  * a ``#define`` providing the correct ``methoddef`` structure for the
+* a ``#define`` providing the correct ``methoddef`` structure for the
   function
-  * a prototype for the "impl" function -- this is what you'll write
+* a prototype for the "impl" function -- this is what you'll write
   to implement this function
-  * a function that handles all argument processing, which calls your
+* a function that handles all argument processing, which calls your
   "impl" function
-  * the definition line of the "impl" function
-  * and a comment indicating the end of output.
+* the definition line of the "impl" function
+* and a comment indicating the end of output.
 
 The intention is that you write the body of your impl function immediately
 after the output -- as in, you write a left-curly-brace immediately after