Use consistent "backwards" adverb and case for heads (#637)

pep-0008.txt

@@ -250,7 +250,7 @@ Another such case is with ``assert`` statements.
 Make sure to indent the continued line appropriately.
 
 
-Should a line break before or after a binary operator?
+Should a Line Break Before or After a Binary Operator?
 ------------------------------------------------------
 
 For decades the recommended style was to break after binary operators.
@@ -333,7 +333,7 @@ technical terms are used which aren't English). In addition, string
 literals and comments must also be in ASCII. The only exceptions are
 (a) test cases testing the non-ASCII features, and
 (b) names of authors. Authors whose names are not based on the
-Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST provide 
+Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST provide
 a transliteration of their names in this character set.
 
 Open source projects with a global audience are encouraged to adopt a
@@ -359,9 +359,9 @@ Imports
 
   Imports should be grouped in the following order:
 
-  1. standard library imports
-  2. related third party imports
-  3. local application/library specific imports
+  1. Standard library imports.
+  2. Related third party imports.
+  3. Local application/library specific imports.
 
   You should put a blank line between each group of imports.
 
@@ -642,7 +642,7 @@ Other Recommendations
 
       if foo == 'blah': one(); two(); three()
 
-When to use trailing commas
+When to Use Trailing Commas
 ===========================
 
 Trailing commas are usually optional, except they are mandatory when
@@ -690,7 +690,7 @@ Comments that contradict the code are worse than no comments.  Always
 make a priority of keeping the comments up-to-date when the code
 changes!
 
-Comments should be complete sentences.  The first word should be 
+Comments should be complete sentences.  The first word should be
 capitalized, unless it is an identifier that begins with a lower case
 letter (never alter the case of identifiers!).
 
@@ -882,7 +882,7 @@ Note that there is a separate convention for builtin names: most builtin
 names are single words (or two words run together), with the CapWords
 convention used only for exception names and builtin constants.
 
-Type variable names
+Type Variable Names
 ~~~~~~~~~~~~~~~~~~~
 
 Names of type variables introduced in PEP 484 should normally use CapWords
@@ -914,7 +914,7 @@ older convention of prefixing such globals with an underscore (which
 you might want to do to indicate these globals are "module
 non-public").
 
-Function and variable names
+Function and Variable Names
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Function names should be lowercase, with words separated by
@@ -926,7 +926,7 @@ mixedCase is allowed only in contexts where that's already the
 prevailing style (e.g. threading.py), to retain backwards
 compatibility.
 
-Function and method arguments
+Function and Method Arguments
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Always use ``self`` for the first argument to instance methods.
@@ -975,7 +975,7 @@ doubt, choose non-public; it's easier to make it public later than to
 make a public attribute non-public.
 
 Public attributes are those that you expect unrelated clients of your
-class to use, with your commitment to avoid backward incompatible
+class to use, with your commitment to avoid backwards incompatible
 changes.  Non-public attributes are those that are not intended to be
 used by third parties; you make no guarantees that non-public
 attributes won't change or even be removed.
@@ -1042,7 +1042,7 @@ With this in mind, here are the Pythonic guidelines:
   advanced callers.
 
 
-Public and internal interfaces
+Public and Internal Interfaces
 ------------------------------
 
 Any backwards compatibility guarantees apply only to public interfaces.
@@ -1301,7 +1301,7 @@ Programming Recommendations
 - Use string methods instead of the string module.
 
   String methods are always much faster and share the same API with
-  unicode strings.  Override this rule if backward compatibility with
+  unicode strings.  Override this rule if backwards compatibility with
   Pythons older than 2.0 is required.
 
 - Use ``''.startswith()`` and ``''.endswith()`` instead of string