PEP 445, PEP 467, PEP 548, PEP 621: Fix incorrect backticks (#1560)

pep-0445.txt

@@ -164,7 +164,7 @@ allocator allocates a larger buffer and writes a pattern to detect buffer
 underflow, buffer overflow and use after free (by filling the buffer with
 the byte ``0xDB``). It uses the original ``PyObject_Malloc()``
 function to allocate memory. So ``PyMem_Malloc()`` and
-``PyMem_Realloc()`` indirectly call``PyObject_Malloc()`` and
+``PyMem_Realloc()`` indirectly call ``PyObject_Malloc()`` and
 ``PyObject_Realloc()``.
 
 This PEP redesigns the debug checks as hooks on the existing allocators

pep-0467.txt

@@ -162,7 +162,7 @@ If an index is asked for that doesn't exist, ``IndexError`` is raised::
 Addition of optimised iterator methods that produce ``bytes`` objects
 ---------------------------------------------------------------------
 
-This PEP proposes that ``bytes`` and ``bytearray``gain an optimised
+This PEP proposes that ``bytes`` and ``bytearray`` gain an optimised
 ``iterbytes`` method that produces length 1 ``bytes`` objects rather than
 integers::
 

pep-0548.rst

@@ -141,7 +141,7 @@ With the new syntax this becomes::
         break if not buf
         t.append(buf)
 
-Reading this we first see the``break``, which obviously applies to
+Reading this we first see the ``break``, which obviously applies to
 the while since it is at the same level of indentation as the loop
 body, and then we read the condition that causes the flow of control
 to change.

pep-0621.rst

@@ -583,7 +583,7 @@ Different structures for the ``readme`` field
 The ``readme`` field had a proposed ``readme_content_type`` field, but
 the authors considered the string/table hybrid more practical for the
 common case while still accommodating the more complex case. Same goes
-for using``long_description`` and a corresponding
+for using ``long_description`` and a corresponding
 ``long_description_content_type`` field.
 
 The ``file`` key in the table format was originally proposed as