Don't have quite so many top level headings

pep-0403.txt

@@ -139,9 +139,21 @@ would be equivalent to::
     def name():
         ...
 
+Syntax Change
+-------------
+
+Syntactically, only one new grammar rule is needed::
+
+    in_stmt: '@in' simple_stmt decorated
+
+Grammar: http://hg.python.org/cpython/file/default/Grammar/Grammar
+
+
+Design Discussion
+=================
 
 Background
-==========
+----------
 
 The question of "multi-line lambdas" has been a vexing one for many
 Python users for a very long time, and it took an exploration of Ruby's
@@ -185,7 +197,7 @@ decorators, but covering a broader set of applications.
 
 
 Relation to PEP 3150
-====================
+--------------------
 
 PEP 3150 (Statement Local Namespaces) described its primary motivation
 as being to elevate ordinary assignment statements to be on par with ``class``
@@ -203,7 +215,7 @@ actual name binding in the current scope.
 
 
 Keyword Choice
-==============
+--------------
 
 The proposal definitely requires *some* kind of prefix to avoid parsing
 ambiguity and backwards compatibility problems with existing constructs.
@@ -227,13 +239,14 @@ but the concept remains the same.
 
 
 Better Debugging Support for Functions and Classes with Short Names
-===================================================================
+-------------------------------------------------------------------
 
 One of the objections to widespread use of lambda expressions is that they
 have a negative effect on traceback intelligibility and other aspects of
-introspection. Similarly objections are raised regarding constructs that
+introspection. Similar objections are raised regarding constructs that
 promote short, cryptic function names (including this one, which requires
-that the name of the trailing definition be supplied at least twice)
+that the name of the trailing definition be supplied at least twice,
+encouraging the use of shorthand placeholder names like ``f``).
 
 However, the introduction of qualified names in PEP 3155 means that even
 anonymous classes and functions will now have different representations if
@@ -250,18 +263,8 @@ will still share representations (aside from the object ID), but this is
 still a major improvement over the historical situation where everything
 *except* the object ID was identical.
 
-Syntax Change
-=============
-
-Syntactically, only one new grammar rule is needed::
-
-    in_stmt: '@in' simple_stmt decorated
-
-Grammar: http://hg.python.org/cpython/file/default/Grammar/Grammar
-
-
 Possible Implementation Strategy
-================================
+--------------------------------
 
 This proposal has at least one titanic advantage over PEP 3150:
 implementation should be relatively straightforward.