From 475b6f0c4e7b7125890c7c600a57b8d16ca5ff0b Mon Sep 17 00:00:00 2001 From: Serhiy Storchaka Date: Sat, 14 Feb 2015 19:49:04 +0200 Subject: [PATCH] Fixed markup of footnotes. --- pep-0345.txt | 5 ++++- pep-0377.txt | 10 +++++----- pep-0383.txt | 22 +++++++++++----------- pep-0403.txt | 2 +- pep-0408.txt | 12 ++++++------ pep-0439.txt | 2 +- pep-3000.txt | 2 +- pep-3111.txt | 12 ++++++------ pep-3153.txt | 2 +- 9 files changed, 36 insertions(+), 33 deletions(-) diff --git a/pep-0345.txt b/pep-0345.txt index 778bec106..d6a92a84f 100644 --- a/pep-0345.txt +++ b/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 ========= diff --git a/pep-0377.txt b/pep-0377.txt index b14af7eae..ccb65127e 100644 --- a/pep-0377.txt +++ b/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``). diff --git a/pep-0383.txt b/pep-0383.txt index 9cdb00681..38acc855b 100644 --- a/pep-0383.txt +++ b/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 - "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 ========= diff --git a/pep-0403.txt b/pep-0403.txt index 2a97caeae..efcdd3217 100644 --- a/pep-0403.txt +++ b/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:: diff --git a/pep-0408.txt b/pep-0408.txt index de00aeae2..461cce649 100644 --- a/pep-0408.txt +++ b/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 diff --git a/pep-0439.txt b/pep-0439.txt index 931b75767..e7b91698f 100644 --- a/pep-0439.txt +++ b/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. diff --git a/pep-3000.txt b/pep-3000.txt index d6946b588..2021c1b88 100644 --- a/pep-3000.txt +++ b/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 diff --git a/pep-3111.txt b/pep-3111.txt index f29db6d61..bdbdc4070 100644 --- a/pep-3111.txt +++ b/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.) -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 diff --git a/pep-3153.txt b/pep-3153.txt index 56ff214fa..15a382bf5 100644 --- a/pep-3153.txt +++ b/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