Fixed markup of footnotes.

This commit is contained in:
Serhiy Storchaka 2015-02-14 19:49:04 +02:00
parent d277ad711a
commit 475b6f0c4e
9 changed files with 36 additions and 33 deletions

View File

@ -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
=========

View File

@ -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``).

View File

@ -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
"Unicode file name support for Windows NT"
http://www.python.org/dev/peps/pep-0277/
.. [1] PEP 277
"Unicode file name support for Windows NT"
http://www.python.org/dev/peps/pep-0277/
[2] PEP 293
"Codec Error Handling Callbacks"
http://www.python.org/dev/peps/pep-0293/
.. [2] PEP 293
"Codec Error Handling Callbacks"
http://www.python.org/dev/peps/pep-0293/
[3] UTF-8b
http://mail.nl.linux.org/linux-utf8/2000-07/msg00040.html
.. [3] UTF-8b
http://mail.nl.linux.org/linux-utf8/2000-07/msg00040.html
Copyright
=========

View File

@ -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::

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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.)
While the BDFL has clearly stated [3] that input() was not to be kept in
see [2]_ and the discussion that followed.)
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

View File

@ -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