Hopefully fix rendering errors for PEP 649.

pep-0649.rst

@@ -83,7 +83,9 @@ Overview
    Implementation_ section later in this PEP for a much more
    accurate description of how this PEP works.
 
-Consider this example code::
+Consider this example code:
+
+.. code-block::
 
     def foo(x: int = 3, y: MyType = None) -> float:
         ...
@@ -100,7 +102,9 @@ fields to the value specified as that field's annotation.
 The default behavior in Python 3.9 is to evaluate the expressions
 for the annotations, and build the annotations dict, at the time
 the function, class, or module is bound.  At runtime the above
-code actually works something like this::
+code actually works something like this:
+
+.. code-block::
 
     annotations = {'x': int, 'y': MyType, 'return': float}
     def foo(x = 3, y = "abc"):
@@ -118,7 +122,9 @@ line, because ``MyType`` hasn't been defined yet.
 
 PEP 563's solution is to decompile the expressions back
 into strings, and store those *strings* in the annotations dict.
-The equivalent runtime code would look something like this::
+The equivalent runtime code would look something like this:
+
+.. code-block::
 
     annotations = {'x': 'int', 'y': 'MyType', 'return': 'float'}
     def foo(x = 3, y = "abc"):
@@ -138,7 +144,9 @@ object.
 This PEP proposes a third approach, delaying the evaluation of
 the annotations by computing them in their own function.  If
 this PEP was active, the generated code would work something
-like this::
+like this:
+
+.. code-block::
 
     class function:
         # __annotations__ on a function object is already a
@@ -215,8 +223,8 @@ PEP 563 while avoiding the problems listed above:
 * Python implementations would generate annotations as code
   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
+  - 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.
 * Existing annotations would not need to be changed to only
@@ -404,7 +412,9 @@ CPython repo.
 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:
+
+.. code-block::
 
     from __future__ import co_annotations
 
@@ -443,7 +453,9 @@ of the ``__co_annotations__`` attribute.
 ``__annotations__`` is also as a data descriptor, with its own
 separate internal storage for its internal value. The code
 implementing the "get" for ``__annotations__`` works something
-like this::
+like this:
+
+.. code-block::
 
     if (the internal value is set)
         return the internal annotations dict
@@ -584,6 +596,8 @@ It's possible to write annotations that refer to
 free variables, and even free variables that have yet
 to be defined.  For example:
 
+.. code-block::
+
     from __future__ import co_annotations
 
     def outer():
@@ -630,6 +644,8 @@ It's possible to write annotations that refer to
 class variables, and even class variables that haven't
 yet been defined.  For example:
 
+.. code-block::
+
     from __future__ import co_annotations
 
     class C: