Fixed markup of footnotes.

pep-0345.txt

@@ -255,7 +255,7 @@ Classifier (multiple use)
 :::::::::::::::::::::::::
 
 Each entry is a string giving a single classification value
-for the distribution.  Classifiers are described in PEP 301 [2].
+for the distribution.  Classifiers are described in PEP 301 [3]_.
 
 Examples::
 
@@ -543,6 +543,9 @@ Version 1.1 is specified in PEP 314.
 .. [2] RFC 822 Long Header Fields:
    http://www.freesoft.org/CIE/RFC/822/7.htm
 
+.. [3] PEP 301, Package Index and Metadata for Distutils:
+   http://www.python.org/dev/peps/pep-0301/
+
 Copyright
 =========
 

pep-0377.txt

@@ -22,7 +22,7 @@ code into a context manager by moving it into a generator function
 with a yield in the appropriate location. One symptom of this is that
 ``contextlib.nested`` will currently raise ``RuntimeError`` in
 situations where writing out the corresponding nested ``with``
-statements would not [1].
+statements would not [1]_.
 
 The proposed change is to introduce a new flow control exception
 ``SkipStatement``, and skip the execution of the ``with``
@@ -32,7 +32,7 @@ statement body if ``__enter__()`` raises this exception.
 PEP Rejection
 =============
 
-This PEP was rejected by Guido [2] as it imposes too great an increase
+This PEP was rejected by Guido [4]_ as it imposes too great an increase
 in complexity without a proportional increase in expressiveness and
 correctness. In the absence of compelling use cases that need the more
 complex semantics proposed by this PEP the existing behaviour is
@@ -51,7 +51,7 @@ clause unbound in this case, a new ``StatementSkipped`` singleton
 (similar to the existing ``NotImplemented`` singleton) will be
 assigned to all names that appear in the ``as`` clause.
 
-The components of the ``with`` statement remain as described in PEP 343 [2]::
+The components of the ``with`` statement remain as described in PEP 343 [2]_::
 
     with EXPR as VAR:
         BLOCK
@@ -221,7 +221,7 @@ a small adjustment to take advantage of the new semantics::
           suppress = self.cmA.__exit__(*args):
       return suppress
 
-There is currently a tentative suggestion [3] to add import-style syntax to
+There is currently a tentative suggestion [3]_ to add import-style syntax to
 the ``with`` statement to allow multiple context managers to be included in
 a single ``with`` statement without needing to use ``contextlib.nested``. In
 that case the compiler has the option of simply emitting multiple ``with``
@@ -249,7 +249,7 @@ than a dozen unnecessary trips around the eval loop).
 Reference Implementation
 ========================
 
-Patch attached to Issue 5251 [1]. That patch uses only existing opcodes
+Patch attached to Issue 5251 [1]_. That patch uses only existing opcodes
 (i.e. no ``SETUP_WITH``).
 
 

pep-0383.txt

@@ -64,7 +64,7 @@ Specification
 
 On Windows, Python uses the wide character APIs to access
 character-oriented APIs, allowing direct conversion of the
-environmental data to Python str objects ([1]).
+environmental data to Python str objects ([1]_).
 
 On POSIX systems, Python currently applies the locale's encoding to
 convert the byte data to Unicode, failing for characters that cannot
@@ -72,7 +72,7 @@ be decoded. With this PEP, non-decodable bytes >= 128 will be
 represented as lone surrogate codes U+DC80..U+DCFF. Bytes below
 128 will produce exceptions; see the discussion below.
 
-To convert non-decodable bytes, a new error handler ([2])
+To convert non-decodable bytes, a new error handler ([2]_)
 "surrogateescape" is introduced, which produces these surrogates. On
 encoding, the error handler converts the surrogate back to the
 corresponding byte. This error handler will be used in any API that
@@ -95,7 +95,7 @@ Discussion
 ==========
 
 This surrogateescape encoding is based on Markus Kuhn's idea that
-he called UTF-8b [3].
+he called UTF-8b [3]_.
 
 While providing a uniform API to non-decodable bytes, this interface
 has the limitation that chosen representation only "works" if the data
@@ -171,16 +171,16 @@ case; other libraries may show similar problems.
 References
 ==========
 
-  [1] PEP 277
+.. [1] PEP 277
-      "Unicode file name support for Windows NT"
+   "Unicode file name support for Windows NT"
-      http://www.python.org/dev/peps/pep-0277/
+   http://www.python.org/dev/peps/pep-0277/
 
-  [2] PEP 293
+.. [2] PEP 293
-      "Codec Error Handling Callbacks"
+   "Codec Error Handling Callbacks"
-      http://www.python.org/dev/peps/pep-0293/
+   http://www.python.org/dev/peps/pep-0293/
 
-  [3] UTF-8b
+.. [3] UTF-8b
-      http://mail.nl.linux.org/linux-utf8/2000-07/msg00040.html
+   http://mail.nl.linux.org/linux-utf8/2000-07/msg00040.html
 
 Copyright
 =========

pep-0403.txt

@@ -428,7 +428,7 @@ see them as two variants of the same idea.
 Anonymous Forward References
 ----------------------------
 
-A previous incarnation of this PEP (see [1]) proposed a syntax where the
+A previous incarnation of this PEP (see [1]_) proposed a syntax where the
 new clause was introduced with ``:`` and the forward reference was written
 using ``@``. Feedback on this variant was almost universally
 negative, as it was considered both ugly and excessively magical::

pep-0408.txt

@@ -32,7 +32,7 @@ PEP Rejection
 =============
 
 Based on his experience with a similar "labs" namespace in Google App Engine,
-Guido has rejected this PEP [3] in favour of the simpler alternative of
+Guido has rejected this PEP [3]_ in favour of the simpler alternative of
 explicitly marking provisional modules as such in their documentation.
 
 If a module is otherwise considered suitable for standard library inclusion,
@@ -42,7 +42,7 @@ an unlikely outcome, such modules *may* be removed from the standard library
 without a deprecation period if the lingering concerns prove well-founded.
 
 As part of the same announcement, Guido explicitly accepted Matthew
-Barnett's 'regex' module [4] as a provisional addition to the standard
+Barnett's 'regex' module [4]_ as a provisional addition to the standard
 library for Python 3.3 (using the 'regex' name, rather than as a drop-in
 replacement for the existing 're' module).
 
@@ -290,15 +290,15 @@ package in a better way.
 References
 ==========
 
-.. [#] Discussed in this thread:
+.. [1] Discussed in this thread:
        http://mail.python.org/pipermail/python-ideas/2012-January/013246.html
 
-.. [#] http://mail.python.org/pipermail/python-ideas/2011-August/011278.html
+.. [2] http://mail.python.org/pipermail/python-ideas/2011-August/011278.html
 
-.. [#] Guido's decision:
+.. [3] Guido's decision:
        http://mail.python.org/pipermail/python-dev/2012-January/115962.html
 
-.. [#] Proposal for inclusion of regex: http://bugs.python.org/issue2636
+.. [4] Proposal for inclusion of regex: http://bugs.python.org/issue2636
 
 
 Copyright

pep-0439.txt

@@ -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\ [3]_ 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.

pep-3000.txt

@@ -48,7 +48,7 @@ Python 3000 before we started the Python 3000 process for real.  PEP
 Timeline
 ========
 
-See PEP 361 [#pep361], which contains the release schedule for Python
+See PEP 361 [#pep361]_, which contains the release schedule for Python
 2.6 and 3.0.  These versions will be released in lockstep.
 
 Note: standard library development is expected to ramp up after 3.0a1

pep-3111.txt

@@ -20,7 +20,7 @@ and two simple means of interactive input through the input()
 and raw_input() built-in functions.
 
 Python 3.0 will introduce various incompatible changes with previous
-Python versions[1].  Among the proposed changes, print will become a built-in
+Python versions\ [1]_.  Among the proposed changes, print will become a built-in
 function, print(), while input() and raw_input() would be removed completely
 from the built-in namespace, requiring importing some module to provide
 even the most basic input capability.
@@ -28,7 +28,7 @@ even the most basic input capability.
 This PEP proposes that Python 3.0 retains some simple interactive user
 input capability, equivalent to raw_input(), within the built-in namespace.
 
-It was accepted by the BDFL in December 2006 [5].
+It was accepted by the BDFL in December 2006 [5]_.
 
 
 Motivation
@@ -42,7 +42,7 @@ and to obtain information from the user (interactive input).
 Any computer language intended to be used in an educational setting should
 provide straightforward methods for both output and interactive input.
 
-The current proposals for Python 3.0 [1] include a simple output pathway
+The current proposals for Python 3.0 [1]_ include a simple output pathway
 via a built-in function named print(), but a more complicated method for
 input [e.g. via sys.stdin.readline()], one that requires importing an external
 module.  Current versions of Python (pre-3.0) include raw_input() as a
@@ -56,8 +56,8 @@ Rationale
 
 Current built-in functions, like input() and raw_input(), are found to be
 extremely useful in traditional teaching settings. (For more details,
-see [2] and the discussion that followed.) 
+see [2]_ and the discussion that followed.) 
-While the BDFL has clearly stated [3] that input() was not to be kept in
+While the BDFL has clearly stated [3]_ that input() was not to be kept in
 Python 3000, he has also stated that he was not against revising the
 decision of killing raw_input().
 
@@ -133,7 +133,7 @@ universal use.  In this instance, the good it does for beginners could be
 seen to outweigh the harm it does to experienced programmers -
 although it could cause confusion for people reading older books or tutorials.
 
-The rationale for accepting the renaming can be found here [4].
+The rationale for accepting the renaming can be found here [4]_.
 
 
 References

pep-3153.txt

@@ -166,7 +166,7 @@ mechanism is used to eventually transfer those bytes.
 This also allows for protocols to be stacked or nested easily,
 allowing for even more code reuse.  A common example of this is
 JSON-RPC: according to the specification, it can be used across both
-sockets and HTTP[#jsonrpc]_ .  In practice, it tends to be primarily
+sockets and HTTP [#jsonrpc]_.  In practice, it tends to be primarily
 encapsulated in HTTP.  The protocol-transport abstraction allows us to
 build a stack of protocols and transports that allow you to use HTTP
 as if it were a transport.  For JSON-RPC, that might get you a stack