PEP 538: Fix footnotes (#2714)

Author: hugovk

pep-0538.txt

@@ -124,7 +124,7 @@ can cause problems in some situations (for example, when using the GNU readline
 module [16_]).
 
 On non-Apple and non-Android \*nix systems, these operations are handled using
-the C locale system in glibc, which has the following characteristics [4_]:
+the C locale system in glibc, which has the following characteristics [4]_:
 
 * by default, all processes start in the ``C`` locale, which uses ``ASCII``
   for these conversions. This is almost never what anyone doing multilingual
@@ -136,7 +136,7 @@ the C locale system in glibc, which has the following characteristics [4_]:
 
 The specific locale category that covers the APIs that CPython depends on is
 ``LC_CTYPE``, which applies to "classification and conversion of characters,
-and to multibyte and wide characters" [5_]. Accordingly, CPython includes the
+and to multibyte and wide characters" [5]_. Accordingly, CPython includes the
 following key calls to ``setlocale``:
 
 * in the main ``python`` binary, CPython calls ``setlocale(LC_ALL, "")`` to
@@ -183,7 +183,7 @@ Mac OS X and other \*BSD systems have taken a different approach: instead of
 offering a ``C.UTF-8`` locale, they offer a partial ``UTF-8`` locale that only
 defines the ``LC_CTYPE`` category. On such systems, the preferred
 environmental locale adjustment is to set ``LC_CTYPE=UTF-8`` rather than to set
-``LC_ALL`` or ``LANG``. [17_]
+``LC_ALL`` or ``LANG``. [17]_
 
 In the specific case of Docker containers and similar technologies, the
 appropriate locale setting can be specified directly in the container image
@@ -247,8 +247,8 @@ Motivation
 While Linux container technologies like Docker, Kubernetes, and OpenShift are
 best known for their use in web service development, the related container
 formats and execution models are also being adopted for Linux command line
-application development. Technologies like Gnome Flatpak [7_] and
-Ubuntu Snappy [8_] further aim to bring these same techniques to Linux GUI
+application development. Technologies like Gnome Flatpak [7]_ and
+Ubuntu Snappy [8]_ further aim to bring these same techniques to Linux GUI
 application development.
 
 When using Python 3 for application development in these contexts, it isn't
@@ -327,7 +327,7 @@ with this problem automatically rather than relying on redistributors or end
 users to handle it through system configuration changes.
 
 While the glibc developers are working towards making the C.UTF-8 locale
-universally available for use by glibc based applications like CPython [6_],
+universally available for use by glibc based applications like CPython [6]_,
 this unfortunately doesn't help on platforms that ship older versions of glibc
 without that feature, and also don't provide C.UTF-8 (or an equivalent) as an
 on-disk locale the way Debian and Fedora do. These platforms are considered
@@ -649,7 +649,7 @@ Defaulting to "surrogateescape" error handling on the standard IO streams
 By coercing the locale away from the legacy C default and its assumption of
 ASCII as the preferred text encoding, this PEP also disables the implicit use
 of the "surrogateescape" error handler on the standard IO streams that was
-introduced in Python 3.5 ([15_]), as well as the automatic use of
+introduced in Python 3.5 ([15]_), as well as the automatic use of
 ``surrogateescape`` when operating in :pep:`540`'s proposed UTF-8 mode.
 
 Rather than introducing yet another configuration option to adjust that
@@ -662,7 +662,7 @@ provided text values are typically able to be transparently passed through a
 Python 3 application even if it is incorrect in assuming that that text has
 been encoded as UTF-8.
 
-In particular, GB 18030 [12_] is a Chinese national text encoding standard
+In particular, GB 18030 [12]_ is a Chinese national text encoding standard
 that handles all Unicode code points, that is formally incompatible with both
 ASCII and UTF-8, but will nevertheless often tolerate processing as surrogate
 escaped data - the points where GB 18030 reuses ASCII byte values in an
@@ -672,7 +672,7 @@ the relevant ASCII code points. Operations that don't involve splitting on or
 searching for particular ASCII or Unicode code point values are almost
 certain to work correctly.
 
-Similarly, Shift-JIS [13_] and ISO-2022-JP [14_] remain in widespread use in
+Similarly, Shift-JIS [13]_ and ISO-2022-JP [14]_ remain in widespread use in
 Japan, and are incompatible with both ASCII and UTF-8, but will tolerate text
 processing operations that don't involve splitting on or searching for
 particular ASCII or Unicode code point values.
@@ -908,7 +908,7 @@ This was later removed on the grounds that setting only ``LC_CTYPE`` is
 sufficient to handle all of the problematic scenarios that the PEP aimed
 to resolve, while setting ``LANG`` as well would break cases where ``LANG``
 was set correctly, and the locale problems were solely due to an incorrect
-``LC_CTYPE`` setting ([22_]).
+``LC_CTYPE`` setting ([22]_).
 
 For example, consider a Python application that called the Linux ``date``
 utility in a subprocess rather than doing its own date formatting::
@@ -1077,7 +1077,7 @@ be entirely redundant.
 However, that assumption turned out to be incorrect, as subsequent
 investigations showed that if you explicitly configure ``LANG=C`` on
 these platforms, extension modules like GNU readline will misbehave in much the
-same way as they do on other \*nix systems. [21_]
+same way as they do on other \*nix systems. [21]_
 
 In addition, Mac OS X is also frequently used as a development and testing
 platform for Python software intended for deployment to other \*nix environments
@@ -1093,12 +1093,12 @@ Implementation
 ==============
 
 The reference implementation is being developed in the
-``pep538-coerce-c-locale`` feature branch [18_] in Nick Coghlan's fork of the
-CPython repository on GitHub. A work-in-progress PR is available at [20_].
+``pep538-coerce-c-locale`` feature branch [18]_ in Nick Coghlan's fork of the
+CPython repository on GitHub. A work-in-progress PR is available at [20]_.
 
 This reference implementation covers not only the enhancement request in
-issue 28180 [1_], but also the Android compatibility fixes needed to resolve
-issue 28997 [16_].
+issue 28180 [1]_, but also the Android compatibility fixes needed to resolve
+issue 28997 [16]_.
 
 
 Backporting to earlier Python 3 releases
@@ -1115,7 +1115,7 @@ default, or else specifically for platforms where such a locale is already
 consistently available.
 
 At least the Fedora project is planning to pursue this approach for the
-upcoming Fedora 26 release [19_].
+upcoming Fedora 26 release [19]_.
 
 
 Backporting to other 3.x releases
@@ -1139,7 +1139,7 @@ Acknowledgements
 
 The locale coercion approach proposed in this PEP is inspired directly by
 Armin Ronacher's handling of this problem in the ``click`` command line
-utility development framework [2_]::
+utility development framework [2]_::
 
     $ LANG=C python3 -c 'import click; cli = click.command()(lambda:None); cli()'
     Traceback (most recent call last):
@@ -1157,18 +1157,18 @@ utility development framework [2_]::
         export LANG=C.UTF-8
 
 The change was originally proposed as a downstream patch for Fedora's
-system Python 3.6 package [3_], and then reformulated as a PEP for Python 3.7
+system Python 3.6 package [3]_, and then reformulated as a PEP for Python 3.7
 with a section allowing for backports to earlier versions by redistributors.
 In parallel with the development of the upstream patch, Charalampos Stratakis
 has been working on the Fedora 26 backport and providing feedback on the
 practical viability of the proposed changes.
 
-The initial draft was posted to the Python Linux SIG for discussion [10_] and
+The initial draft was posted to the Python Linux SIG for discussion [10]_ and
 then amended based on both that discussion and Victor Stinner's work in
-:pep:`540` [11_].
+:pep:`540` [11]_.
 
 The "ℙƴ☂ℌøἤ" string used in the Unicode handling examples throughout this PEP
-is taken from Ned Batchelder's excellent "Pragmatic Unicode" presentation [9_].
+is taken from Ned Batchelder's excellent "Pragmatic Unicode" presentation [9]_.
 
 Stephen Turnbull has long provided valuable insight into the text encoding
 handling challenges he regularly encounters at the University of Tsukuba
@@ -1179,16 +1179,16 @@ References
 ==========
 
 .. [1] CPython: sys.getfilesystemencoding() should default to utf-8
-   (http://bugs.python.org/issue28180)
+   (https://bugs.python.org/issue28180)
 
 .. [2] Locale configuration required for click applications under Python 3
-   (http://click.pocoo.org/5/python3/#python-3-surrogate-handling)
+   (https://click.palletsprojects.com/en/5.x/python3/#python-3-surrogate-handling)
 
 .. [3] Fedora: force C.UTF-8 when Python 3 is run under the C locale
    (https://bugzilla.redhat.com/show_bug.cgi?id=1404918)
 
 .. [4] GNU C: How Programs Set the Locale
-   ( https://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html)
+   (https://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html)
 
 .. [5] GNU C: Locale Categories
    (https://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html)
@@ -1197,13 +1197,13 @@ References
    (https://sourceware.org/glibc/wiki/Proposals/C.UTF-8)
 
 .. [7] GNOME Flatpak
-   (http://flatpak.org/)
+   (https://flatpak.org/)
 
 .. [8] Ubuntu Snappy
    (https://www.ubuntu.com/desktop/snappy)
 
 .. [9] Pragmatic Unicode
-   (http://nedbatchelder.com/text/unipain.html)
+   (https://nedbatchelder.com/text/unipain.html)
 
 .. [10] linux-sig discussion of initial PEP draft
    (https://mail.python.org/pipermail/linux-sig/2017-January/000014.html)
@@ -1224,10 +1224,10 @@ References
    (https://bugs.python.org/issue19977)
 
 .. [16] test_readline.test_nonascii fails on Android
-   (http://bugs.python.org/issue28997)
+   (https://bugs.python.org/issue28997)
 
 .. [17] UTF-8 locale discussion on "locale.getdefaultlocale() fails on Mac OS X with default language set to English"
-   (http://bugs.python.org/issue18378#msg215215)
+   (https://bugs.python.org/issue18378#msg215215)
 
 .. [18] GitHub branch diff for ``ncoghlan:pep538-coerce-c-locale``
    (https://github.com/python/cpython/compare/master...ncoghlan:pep538-coerce-c-locale)
@@ -1250,13 +1250,3 @@ Copyright
 
 This document has been placed in the public domain under the terms of the
 CC0 1.0 license: https://creativecommons.org/publicdomain/zero/1.0/
-
-
-..
-   Local Variables:
-   mode: indented-text
-   indent-tabs-mode: nil
-   sentence-end-double-space: t
-   fill-column: 70
-   coding: utf-8
-   End: