Use :: for all examples, fix name.
It turns out docutils thinks my first initial is the first element of a numbered list if it is followed by a period. 'make' now completes successfully.
This commit is contained in:
parent
2454632cd6
commit
6556f2a904
36
pep-0548.rst
36
pep-0548.rst
|
@ -2,7 +2,7 @@ PEP: 548
|
|||
Title: More Flexible Loop Control
|
||||
Version: $Revision$
|
||||
Last-Modified: $Date$
|
||||
Author: R. David Murray
|
||||
Author: R David Murray
|
||||
Status: Draft
|
||||
Type: Standards Track
|
||||
Content-Type: text/x-rst
|
||||
|
@ -26,7 +26,7 @@ Motivation
|
|||
It is often necessary for some code to be executed before each
|
||||
evaluation of the while loop condition. This code is often
|
||||
duplicated outside the loop, as setup code that executes once
|
||||
before entering the loop:
|
||||
before entering the loop::
|
||||
|
||||
<setup code>
|
||||
while <condition>:
|
||||
|
@ -34,7 +34,7 @@ Motivation
|
|||
<setup code>
|
||||
|
||||
That PEP was rejected because no syntax was found that was superior
|
||||
to the following form:
|
||||
to the following form::
|
||||
|
||||
while True:
|
||||
<setup code>
|
||||
|
@ -50,12 +50,12 @@ Motivation
|
|||
Syntax
|
||||
|
||||
The syntax of the break and continue statements are extended
|
||||
as follows:
|
||||
as follows::
|
||||
|
||||
break_stmt : "break" ["if" expression]
|
||||
continue_stmt : "continue" ["if" expression]
|
||||
|
||||
In addition, the syntax of the while statement is modified as follows:
|
||||
In addition, the syntax of the while statement is modified as follows::
|
||||
|
||||
while_stmt : while1_stmt|while2_stmt
|
||||
while1_stmt : "while" expression ":" suite
|
||||
|
@ -79,7 +79,7 @@ Semantics
|
|||
|
||||
Justification
|
||||
|
||||
The previous "best possible" form:
|
||||
The previous "best possible" form::
|
||||
|
||||
while True:
|
||||
<setup code>
|
||||
|
@ -87,7 +87,7 @@ Justification
|
|||
break
|
||||
<loop body>
|
||||
|
||||
could be formatted as:
|
||||
could be formatted as::
|
||||
|
||||
while True:
|
||||
<setup code>
|
||||
|
@ -95,7 +95,7 @@ Justification
|
|||
<loop body>
|
||||
|
||||
This is superficially almost identical to the form proposed by this
|
||||
PEP:
|
||||
PEP::
|
||||
|
||||
while:
|
||||
<setup code>
|
||||
|
@ -108,7 +108,7 @@ Justification
|
|||
when reading colorized code.
|
||||
|
||||
For example, this is a common code pattern, taken in this case
|
||||
from the tarfile module:
|
||||
from the tarfile module::
|
||||
|
||||
while True:
|
||||
buf = self._read(self.bufsize)
|
||||
|
@ -122,7 +122,7 @@ Justification
|
|||
triggers it; or, we read the condition and only afterward discover
|
||||
that this condition changes the flow of the loop.
|
||||
|
||||
With the new syntax this becomes:
|
||||
With the new syntax this becomes::
|
||||
|
||||
while:
|
||||
buf = self._read(self.bufsize)
|
||||
|
@ -134,7 +134,7 @@ Justification
|
|||
body, and then we read the condition that causes the flow of control
|
||||
to change.
|
||||
|
||||
Further, consider a more complex example from sre_parse:
|
||||
Further, consider a more complex example from sre_parse::
|
||||
|
||||
while True:
|
||||
c = self.next
|
||||
|
@ -153,7 +153,7 @@ Justification
|
|||
|
||||
This is the natural way to write this code given current Python
|
||||
loop control syntax. However, given ``break if``, it would be more
|
||||
natural to write this as follows:
|
||||
natural to write this as follows::
|
||||
|
||||
while:
|
||||
c = self.next
|
||||
|
@ -175,21 +175,21 @@ Justification
|
|||
The proposed syntax also provides a natural, Pythonic spelling of
|
||||
the classic ``repeat ... until <expression>`` construct found in
|
||||
other languages, and for which no good syntax has previously been
|
||||
found for Python:
|
||||
found for Python::
|
||||
|
||||
while:
|
||||
...
|
||||
break if <expression>
|
||||
|
||||
The tarfile module, for example, has a couple of "read until" loops like
|
||||
the following:
|
||||
the following::
|
||||
|
||||
while True:
|
||||
s = self.__read(1)
|
||||
if not s or s == NUL:
|
||||
break
|
||||
|
||||
With the new syntax this would read more clearly:
|
||||
With the new syntax this would read more clearly::
|
||||
|
||||
while:
|
||||
s = self.__read(1)
|
||||
|
@ -199,7 +199,7 @@ Justification
|
|||
but buttressed by the value of consistency.
|
||||
|
||||
It is much more common for a ``continue`` statement to be at the
|
||||
end of a multiline if suite, such as this example from zipfile :
|
||||
end of a multiline if suite, such as this example from zipfile ::
|
||||
|
||||
while True:
|
||||
try:
|
||||
|
@ -214,7 +214,7 @@ Justification
|
|||
The only opportunity for improvement the new syntax would offer for
|
||||
this loop would be the omission of the ``True`` token.
|
||||
|
||||
On the other hand, consider this example from uuid.py:
|
||||
On the other hand, consider this example from uuid.py::
|
||||
|
||||
for i in range(adapters.length):
|
||||
ncb.Reset()
|
||||
|
@ -235,7 +235,7 @@ Justification
|
|||
continue
|
||||
return int.from_bytes(bytes, 'big')
|
||||
|
||||
This becomes:
|
||||
This becomes::
|
||||
|
||||
for i in range(adapters.length):
|
||||
ncb.Reset()
|
||||
|
|
Loading…
Reference in New Issue