diff --git a/pep-0605.rst b/pep-0605.rst
index 4e6bccc41fc..e76f1a7da9a 100644
--- a/pep-0605.rst
+++ b/pep-0605.rst
@@ -508,7 +508,7 @@ full CPython C ABI:
   built against the full CPython ABI in the preceding pre-release are expected
   to load correctly, as long as those modules abide by the following additional
   criteria:
-  
+
   * the module must not be using any provisional or private C APIs (either from
     the previous stable release series, or the in development pre-release series)
     that were removed in this beta release, or were changed in an ABI incompatible
@@ -621,7 +621,7 @@ the X.Y.0 release.
 Changes to management of the CPython stable C ABI
 -------------------------------------------------
 
-The CPython stable ABI [5_] makes the commitment that binary extension modules
+The CPython stable ABI [5]_ makes the commitment that binary extension modules
 built against any particular CPython release will continue to work on future
 CPython releases that support the same stable ABI version (this version is
 currently ``abi3``).
@@ -752,7 +752,7 @@ On Windows systems, the suffix for tagged ``pyd`` files in pre-release builds
 would include "p" as a pre-release marker immediately after the version number,
 giving markers like "cp39p-win_amd64".
 
-A proposed reference implementation for this change is available at [4_] (Note:
+A proposed reference implementation for this change is available at [4]_ (Note:
 at time of writing, that implementation had not yet been tested on Windows).
 
 
@@ -911,12 +911,12 @@ final release.
 Why not use Calendar Versioning for the rolling release stream?
 ---------------------------------------------------------------
 
-Steve Dower's initial write-up of this proposal [1_] suggested the use of
+Steve Dower's initial write-up of this proposal [1]_ suggested the use of
 calendar versioning for the rolling release stream (so the first rolling
 pre-release after Python 3.8.0 would have been Python 2019.12 rather than
 3.9.0b1).
 
-Paul Moore pointed out [2_] two major practical problems with that proposal:
+Paul Moore pointed out [2]_ two major practical problems with that proposal:
 
 * it isn't going to be clear to users of the calendar-based versions where they
   stand in relation to the traditionally numbered versions
@@ -1114,14 +1114,14 @@ Having a rolling pre-freeze release stream available may also make it more feasi
 for more CI providers to offer a "CPython beta release" testing option. At the
 moment, this feature is only available from CI providers that are willing and
 able to put the necessary time and effort into creating, testing, and publishing
-their own builds from the CPython master branch (e.g. [6_]).
+their own builds from the CPython master branch (e.g. [6]_).
 
 
 Implications for the proposed Scientific Python ecosystem support period
 ------------------------------------------------------------------------
 
 Based on discussions at SciPy 2019, NEP (NumPy Enhancement Proposal) 29 has
-been drafted [3_] to propose a common convention across the Scientific Python
+been drafted [3]_ to propose a common convention across the Scientific Python
 ecosystem for dropping support for older Python versions.
 
 While the exact formulation of that policy is still being discussed, the draft
@@ -1366,12 +1366,3 @@ Copyright
 
 This document is placed in the public domain or under the CC0-1.0-Universal
 license, whichever is more permissive.
-
-..
-  Local Variables:
-  mode: indented-text
-  indent-tabs-mode: nil
-  sentence-end-double-space: t
-  fill-column: 80
-  coding: utf-8
-  End: