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:
toonarmycaptain 2017-11-05 18:52:16 -06:00 committed by Barry Warsaw
parent feedbb46c4
commit ef1eb2f868
1 changed files with 5 additions and 5 deletions

View File

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