Fixed markup of footnotes.
This commit is contained in:
parent
d277ad711a
commit
475b6f0c4e
|
@ -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
|
||||
=========
|
||||
|
||||
|
|
10
pep-0377.txt
10
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``).
|
||||
|
||||
|
||||
|
|
12
pep-0383.txt
12
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,15 +171,15 @@ case; other libraries may show similar problems.
|
|||
References
|
||||
==========
|
||||
|
||||
[1] PEP 277
|
||||
.. [1] PEP 277
|
||||
"Unicode file name support for Windows NT"
|
||||
http://www.python.org/dev/peps/pep-0277/
|
||||
|
||||
[2] PEP 293
|
||||
.. [2] PEP 293
|
||||
"Codec Error Handling Callbacks"
|
||||
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
|
||||
|
||||
Copyright
|
||||
|
|
|
@ -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::
|
||||
|
|
12
pep-0408.txt
12
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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
12
pep-3111.txt
12
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
|
||||
|
|
Loading…
Reference in New Issue