Update pep-0008.txt (#438)
* Update pep-0008.txt Clarified contradictions regarding comment formatting. NB Complete sentences should have a period. * Update pep-0008.txt Changed to remove reference to short comments without terminating period. * Update pep-0008.txt Further refined, corrected incorrect, fixed singular/plural. * Update pep-0008.txt * Update pep-0008.txt Edit for consistency use 'multi-' in 'multi-line` 'multi-statement` 'multi-sentence` etc with dash rather than space or no splitter (eg 'multi line`, 'multiline`). If a different convention is preferred, do that. * Update pep-0008.txt 'latin' capitalization 'Latin' is a proper noun, and thus should be capitalized. * Update pep-0008.txt 'boolean' capitalization Capitalization should be consisted. I propose 'boolean' should always be capitalized, as per https://english.stackexchange.com/questions/4481/should-the-word-boolean-be-capitalized At present it is inconsistently capitalised. Changed 'boolean' to 'Boolean' * Update pep-0008.txt - 'unicode' capitalization Update pep-0008.txt - as a proper noun, 'unicode' should be capitalized. Fixed 3 instances. * Revise Update pep-0008.txt Removed revisions to 'boolean', 'unicode'. Unicode capitalization [issue](https://bugs.python.org/issue31873) under discussion. * Removed trailing newlines Removed trailing newlines * Standardised 'multiline', reworded 'Latin' Made the form 'multiline' uniform throughout the document. Clarified references to Latin alphabet to direct to the specific character set desired. * Removed errant period * Moved 'alphabet' Moved 'alphabet' before encoding parenthesis line 336.
This commit is contained in:
parent
feedbb46c4
commit
ef1eb2f868
10
pep-0008.txt
10
pep-0008.txt
|
@ -154,7 +154,7 @@ Acceptable options in this situation include, but are not limited to::
|
|||
(Also see the discussion of whether to break before or after binary
|
||||
operators below.)
|
||||
|
||||
The closing brace/bracket/parenthesis on multi-line constructs may
|
||||
The closing brace/bracket/parenthesis on multiline constructs may
|
||||
either line up under the first non-whitespace character of the last
|
||||
line of list, as in::
|
||||
|
||||
|
@ -168,7 +168,7 @@ line of list, as in::
|
|||
)
|
||||
|
||||
or it may be lined up under the first character of the line that
|
||||
starts the multi-line construct, as in::
|
||||
starts the multiline construct, as in::
|
||||
|
||||
my_list = [
|
||||
1, 2, 3,
|
||||
|
@ -333,8 +333,8 @@ technical terms are used which aren't English). In addition, string
|
|||
literals and comments must also be in ASCII. The only exceptions are
|
||||
(a) test cases testing the non-ASCII features, and
|
||||
(b) names of authors. Authors whose names are not based on the
|
||||
latin alphabet MUST provide a latin transliteration of their
|
||||
names.
|
||||
Latin alphabet (latin-1, ISO/IEC 8859-1 character set) MUST provide
|
||||
a transliteration of their names in this character set.
|
||||
|
||||
Open source projects with a global audience are encouraged to adopt a
|
||||
similar policy.
|
||||
|
@ -697,7 +697,7 @@ letter (never alter the case of identifiers!).
|
|||
Block comments generally consist of one or more paragraphs built out of
|
||||
complete sentences, with each sentence ending in a period.
|
||||
|
||||
You should use two spaces after a sentence-ending period in multi
|
||||
You should use two spaces after a sentence-ending period in multi-
|
||||
sentence comments, except after the final sentence.
|
||||
|
||||
When writing English, follow Strunk and White.
|
||||
|
|
Loading…
Reference in New Issue