Trivial updates, including sequencing footnotes and add comma.

pep-0331.txt

@@ -39,13 +39,13 @@ is currently implemented only in Python-space; C libraries invoked
 from the Python runtime are unaware of Python's ``LC_NUMERIC``
 setting.  This is done to avoid changing the behavior of certain
 low-level functions that are used by the Python parser and related
-code [2]_.
+code [1]_.
 
 However, this presents a problem for extension modules that wrap C
 libraries.  Applications that use these extension modules will
 inconsistently display and convert floating-point values.
 
-James Henstridge, the author of PyGTK [3]_, has additionally
+James Henstridge, the author of PyGTK [2]_, has additionally
 pointed out that the ``setlocale()`` function also presents
 thread-safety issues, since a thread may call the C library
 ``setlocale()`` outside of the GIL, and cause Python to parse and
@@ -66,7 +66,7 @@ Example Problem
 ===============
 
 The initial problem that motivated this PEP is related to the
-GtkSpinButton [4]_ widget in the GTK+ UI toolkit, wrapped by the
+GtkSpinButton [3]_ widget in the GTK+ UI toolkit, wrapped by the
 PyGTK module.  The widget can be set to numeric mode, and when
 this occurs, characters typed into it are evaluated as a number.
 
@@ -123,18 +123,18 @@ Potential Code Contributions
 ============================
 
 This problem was initially reported as a problem in the GTK+
-libraries [5]_; since then it has been correctly diagnosed as an
+libraries [4]_; since then it has been correctly diagnosed as an
 inconsistency in Python's implementation.  However, in a fortunate
 coincidence, the glib library (developed primarily for GTK+, not
 to be confused with the GNU C library) implements a number of
-``LC_NUMERIC``-agnostic functions (for an example, see [6]_) for
+``LC_NUMERIC``-agnostic functions (for an example, see [5]_) for
 reasons similar to those presented in this paper.
 
 In the same GTK+ problem report, Havoc Pennington suggested that
 the glib authors would be willing to contribute this code to the
 PSF, which would simplify implementation of this PEP considerably.
 Alex Larsson, the original author of the glib code, submitted a
-PSF Contributor Agreement [7]_ on 2003-08-20 [8]_ to ensure the code
+PSF Contributor Agreement [6]_ on 2003-08-20 [7]_ to ensure the code
 could be safely integrated; this agreement has been received and
 accepted.
 
@@ -153,7 +153,7 @@ as members of the GTK+ and glib teams have said they are fine with
 relicensing the code, and a PSF contributor agreement has been
 mailed in to ensure this safety.
 
-Tim Peters has pointed out [9]_ that there are situations involving
+Tim Peters has pointed out [8]_ that there are situations involving
 threading in which the proposed change is insufficient to solve
 the problem completely.  A complete solution, however, does not
 currently exist.
@@ -163,41 +163,41 @@ Implementation
 ==============
 
 An implementation was developed by Gustavo Carneiro <gjc at
-inescporto.pt>, and attached to Sourceforge.net bug 774665 [10]_
+inescporto.pt>, and attached to Sourceforge.net bug 774665 [9]_
 
-The final patch [11]_ was integrated into Python CVS by Martin v.
+The final patch [10]_ was integrated into Python CVS by Martin v.
 Löwis on 2004-06-08, as stated in the bug report.
 
 
 References
 ==========
 
-.. [2] Python locale documentation for embedding,
+.. [1] Python locale documentation for embedding,
        http://docs.python.org/library/locale.html
 
-.. [3] PyGTK homepage, http://www.daa.com.au/~james/pygtk/
+.. [2] PyGTK homepage, http://www.daa.com.au/~james/pygtk/
 
-.. [4] GtkSpinButton screenshot (demonstrating problem),
+.. [3] GtkSpinButton screenshot (demonstrating problem),
        http://www.async.com.br/~kiko/spin.png
 
-.. [5] GNOME bug report, http://bugzilla.gnome.org/show_bug.cgi?id=114132
+.. [4] GNOME bug report, http://bugzilla.gnome.org/show_bug.cgi?id=114132
 
-.. [6] Code submission of g_ascii_strtod and g_ascii_dtostr (later
+.. [5] Code submission of g_ascii_strtod and g_ascii_dtostr (later
        renamed g_ascii_formatd) by Alex Larsson,
        http://mail.gnome.org/archives/gtk-devel-list/2001-October/msg00114.html
 
-.. [7] PSF Contributor Agreement,
+.. [6] PSF Contributor Agreement,
        https://www.python.org/psf/contrib/contrib-form/
 
-.. [8] Alex Larsson's email confirming his agreement was mailed in,
+.. [7] Alex Larsson's email confirming his agreement was mailed in,
        https://mail.python.org/pipermail/python-dev/2003-August/037755.html
 
-.. [9] Tim Peters' email summarizing LC_NUMERIC trouble with Spambayes,
+.. [8] Tim Peters' email summarizing LC_NUMERIC trouble with Spambayes,
        https://mail.python.org/pipermail/python-dev/2003-September/037898.html
 
-.. [10] Python bug report, https://bugs.python.org/issue774665
+.. [9] Python bug report, https://bugs.python.org/issue774665
 
-.. [11] Integrated LC_NUMERIC-agnostic patch,
+.. [10] Integrated LC_NUMERIC-agnostic patch,
         https://sourceforge.net/tracker/download.php?group_id=5470&atid=305470&file_id=89685&aid=774665
 
 

pep-0439.txt

@@ -188,7 +188,7 @@ Implementation
 ==============
 
 The changes to pip required by this PEP are being tracked in that project's
-issue tracker [2]_. Most notably, the addition of --bootstrap and --bootstrap-
+issue tracker [1]_. Most notably, the addition of --bootstrap and --bootstrap-
 to-system to the pip command-line.
 
 It would be preferable that the pip and setuptools projects distribute a wheel
@@ -214,7 +214,7 @@ revocation.
 There is a Perl package installer also named "pip". It is quite rare and not
 commonly used. The Fedora variant of Linux has historically named Python's
 "pip" as "python-pip" and Perl's "pip" as "perl-pip".  This policy has been
-altered\ [3]_ so that future and upgraded Fedora installations will use the name
+altered\ [2]_ so that future and upgraded Fedora installations will use the name
 "pip" for Python's "pip". Existing (non-upgraded) installations will still
 have the old name for the Python "pip", though the potential for confusion is
 now much reduced.
@@ -223,10 +223,10 @@ now much reduced.
 References
 ==========
 
-.. [2] pip issue tracking work needed for this PEP
+.. [1] pip issue tracking work needed for this PEP
        https://github.com/pypa/pip/issues/863
 
-.. [3] Fedora's python-pip package does not provide /usr/bin/pip
+.. [2] Fedora's python-pip package does not provide /usr/bin/pip
        https://bugzilla.redhat.com/show_bug.cgi?id=958377
 
 

pep-0444.txt

@@ -462,7 +462,7 @@ attributes of the ``body`` iterable returned by the application.
 
 The ``environ`` dictionary is required to contain various CGI
 environment variables, as defined by the Common Gateway Interface
-specification [2]_.
+specification [1]_.
 
 The following CGI variables **must** be present.  Each key is a native
 string.  Each value is a bytes instance.
@@ -538,7 +538,7 @@ A server or gateway **should** attempt to provide as many other CGI
 variables as are applicable, each with a string for its key and a
 bytes instance for its value.  In addition, if SSL is in use, the
 server or gateway **should** also provide as many of the Apache SSL
-environment variables [4]_ as are applicable, such as ``HTTPS=on`` and
+environment variables [3]_ as are applicable, such as ``HTTPS=on`` and
 ``SSL_PROTOCOL``.  Note, however, that an application that uses any
 CGI variables other than the ones listed above are necessarily
 non-portable to web servers that do not support the relevant
@@ -1408,7 +1408,7 @@ Here are some alternatives to using all bytes:
 Applications Should be Allowed to Read ``web3.input`` Past ``CONTENT_LENGTH``
 -----------------------------------------------------------------------------
 
-At [5]_, Graham Dumpleton makes the assertion that ``wsgi.input``
+At [4]_, Graham Dumpleton makes the assertion that ``wsgi.input``
 should be required to return the empty string as a signifier of
 out-of-data, and that applications should be allowed to read past the
 number of bytes specified in ``CONTENT_LENGTH``, depending only upon
@@ -1434,7 +1434,7 @@ There's no documented way to indicate that there is content in
 ``read()`` of ``web3.input`` Should Support No-Size Calling Convention
 ----------------------------------------------------------------------
 
-At [5]_, Graham Dumpleton makes the assertion that the ``read()``
+At [4]_, Graham Dumpleton makes the assertion that the ``read()``
 method of ``wsgi.input`` should be callable without arguments, and
 that the result should be "all available request content".  Needs
 discussion.
@@ -1447,7 +1447,7 @@ Open for discussions though.
 Input Filters should set environ ``CONTENT_LENGTH`` to -1
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-At [5]_, Graham Dumpleton suggests that an input filter might set
+At [4]_, Graham Dumpleton suggests that an input filter might set
 ``environ['CONTENT_LENGTH']`` to -1 to indicate that it mutated the
 input.
 
@@ -1492,7 +1492,7 @@ if the server performs URL rewriting.
 Long Response Headers
 ---------------------
 
-Bob Brewer notes on Web-SIG [6]_:
+Bob Brewer notes on Web-SIG [5]_:
 
     Each header_value must not include any control characters,
     including carriage returns or linefeeds, either embedded or at the
@@ -1504,10 +1504,10 @@ Bob Brewer notes on Web-SIG [6]_:
 That's understandable, but HTTP headers are defined as (mostly)
 \*TEXT, and "words of \*TEXT MAY contain characters from character
 sets other than ISO-8859-1 only when encoded according to the rules of
-:rfc:`2047`."  [2]_ And :rfc:`2047` specifies that "an 'encoded-word' may
+:rfc:`2047`."  [1]_ And :rfc:`2047` specifies that "an 'encoded-word' may
 not be more than 75 characters long...  If it is desirable to encode
 more text than will fit in an 'encoded-word' of 75 characters,
-multiple 'encoded-word's (separated by CRLF SPACE) may be used." [3]_
+multiple 'encoded-word's (separated by CRLF SPACE) may be used." [2]_
 This satisfies HTTP header folding rules, as well: "Header fields can
 be extended over multiple lines by preceding each extra line with at
 least one SP or HT." (:pep:`333`)
@@ -1544,18 +1544,18 @@ has all been read in.  Neither WSGI nor Web3 currently supports them.
 References
 ==========
 
-.. [2] The Common Gateway Interface Specification, v 1.1, 3rd Draft
+.. [1] The Common Gateway Interface Specification, v 1.1, 3rd Draft
    (https://datatracker.ietf.org/doc/html/draft-coar-cgi-v11-03)
 
-.. [3] "Chunked Transfer Coding" -- HTTP/1.1, :rfc:`2616#section-3.6.1`
+.. [2] "Chunked Transfer Coding" -- HTTP/1.1, :rfc:`2616#section-3.6.1`
 
-.. [4] mod_ssl Reference, "Environment Variables"
+.. [3] mod_ssl Reference, "Environment Variables"
    (http://www.modssl.org/docs/2.8/ssl_reference.html#ToC25)
 
-.. [5] Details on WSGI 1.0 amendments/clarifications.
+.. [4] Details on WSGI 1.0 amendments/clarifications.
    (http://blog.dscpl.com.au/2009/10/details-on-wsgi-10-amendmentsclarificat.html)
 
-.. [6] [Web-SIG] WSGI and long response header values
+.. [5] [Web-SIG] WSGI and long response header values
    https://mail.python.org/pipermail/web-sig/2006-September/002244.html
 
 Copyright

pep-0488.txt

@@ -91,7 +91,7 @@ based on the interpreter's optimization level (none, ``-O``, and
 
 Currently bytecode file names are created by
 ``importlib.util.cache_from_source()``, approximately using the
-following expression defined by :pep:`3147` [3]_, [4]_::
+following expression defined by :pep:`3147`, [3]_, [4]_::
 
     '{name}.{cache_tag}.pyc'.format(name=module_name,
                                     cache_tag=sys.implementation.cache_tag)