Minor formatting touch-ups for PEP 649.

pep-0649.rst

@@ -109,9 +109,9 @@ this PEP was active, the generated code would work something
 like this::
 
     class function:
-        @property
         # __annotations__ on a function object is already a
-        # "data descriptor", we're just changing what it does
+        # "data descriptor" in Python, we're just changing what it does
+        @property
         def __annotations__(self):
             return self.__co_annotations__()
 
@@ -128,7 +128,7 @@ like this::
 
 The important change is that the code constructing the
 annotations dict now lives in a function—here, called
-`` foo_annotations__fn()``.  But this function isn't called
+``foo_annotations__fn()``.  But this function isn't called
 until we ask for the value of ``foo.__annotations__``,
 and we don't do that until *after* the definition of ``MyType``.
 So this code also runs successfully, and ``foo_y_type`` now
@@ -143,13 +143,13 @@ static type analysis painful due to forward reference problems.
 This was the main justification for PEP 563, and we need not
 revisit those arguments here.
 
-However, PEP 563's solution was to de-compile code for Python
+However, PEP 563's solution was to decompile code for Python
 annotations back into strings at compile time, requiring
-users of annotations to ``eval()`` those strings to turn them
-back into Python values.  This has several drawbacks:
+users of annotations to ``eval()`` those strings to restore
+them to their actual Python values.  This has several drawbacks:
 
 * It requires Python implementations to stringize their
-  annotations.  This is surprising—unprecedented behavior
+  annotations.  This is surprising behavior—unprecedented
   for a language-level feature.  Also, adding this feature
   to CPython was complicated, and this complicated code would
   need to be reimplemented independently by every other Python
@@ -177,10 +177,10 @@ PEP 563 while avoiding the problems listed above:
   objects.  This is simpler than stringizing, and is something
   Python implementations are already quite good at.  This means:
 
- * alternate implementations would need to write less code
-   to implement this feature, and
- * the implementation would be simpler overall, which should
-   reduce its ongoing maintenance cost.
+  - alternate implementations would need to write less code
+    to implement this feature, and
+  - the implementation would be simpler overall, which should
+    reduce its ongoing maintenance cost.
 
 * Code examining annotations at runtime would no longer need
   to use ``eval()`` or anything else—it would automatically
@@ -340,7 +340,7 @@ repo is many months behind.
 from __future__ import co_annotations
 -------------------------------------
 
-In the prototype, the semantics presented in this PEP are gated with:
+In the prototype, the semantics presented in this PEP are gated with::
 
     from __future__ import co_annotations
 
@@ -363,10 +363,10 @@ With this PEP, each of these types adds a new attribute,
 * ``__annotations__`` and ``__co_annotations__`` can't both
   be set to a useful value simultaneously:
 
- * If you set ``__annotations__`` to a dict, this also sets
-   ``__co_annotations__`` to None.
- * If you set ``__co_annotations__`` to a callable, this also
-   deletes ``__annotations__``
+  - If you set ``__annotations__`` to a dict, this also sets
+    ``__co_annotations__`` to None.
+  - If you set ``__co_annotations__`` to a callable, this also
+    deletes ``__annotations__``
 
 Internally, ``__co_annotations__`` is a "data descriptor",
 where functions are called whenever user code gets, sets,
@@ -417,7 +417,7 @@ The annotations function
 ------------------------
 
 Annotations functions take no arguments and
-must return a dict (or subclass of dict).
+must return either None or a dict (or subclass of dict).
 
 The bytecode generated for annotations code objects
 always uses the ``BUILD_CONST_KEY_MAP`` opcode to build the
@@ -485,9 +485,9 @@ it has bound it to a function, or because ``__annotations__``
 has been explicitly set--it also deletes its ``__globals__``
 attribute.
 
-As discussed above, examination / modification of
+As discussed above, examination or modification of
 ``__annotations__`` from within the class body is no
-longer supported.  Also, any flow control (``if`` / ``try``)
+longer supported.  Also, any flow control (``if`` or ``try`` blocks)
 around declarations of members with annotations is unsupported.
 
 If you delete the ``__annotations__`` attribute of a class,