Changes detected by Topy (https://github.com/intgr/topy), all changes
verified by hand, false positives have been omitted.
These range from straight-out misspellings to debatable hyphen placement.
The hyphen changes are supported by grammar manuals of style.
Instead of requiring that comments be written in Strunk & White Standard English, require instead that English-language comments be clear and easily understandable by other English speakers. This accomplishes the same goal without upholding relics of white supremacy. Many native English speakers do not use Standard English as their native dialect, so requiring conformation to Standard English centers whiteness in an inappropriate and unnecessary way, and can alienate and put up barriers for people of color and those whose native dialect of English is not Standard English. This change is a simple way to correct that while maintaining the original intent of the requirement.
Previously, the PEP contained roughly the following three rules, in sequence:
1. Never use spaces around `=` when used to indicate a parameter default
2. Something unrelated
3. DO use spaces around `=` when used to indicate a parameter default if there is also a parameter annotation present
This commit attempts to clarify this part of the PEP by:
* Combining the first and third rules listed above into a single rule that addresses both annotated and unannotated parameters
* Rephrasing the first rule to indicate that it applies only to unannotated parameters, to eliminate the logical contradiction
* 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.
PEP 3131 (Unicode identifiers) includes a policy section
covering their use within the standard library.
This adds an explicit cross-reference to that section from
the prescriptive naming conventions section of PEP 8.
Previous wording used the term "function annotations" which is overly generic. This commit modifies the wording to make it clear we don't mean arbitrary function annotations.
Patch by Brandon Rhodes provides clarity and rationale for this suggestion.
Also fixes the example to use "+", "-" operators which have same precedence
level.
Reviewed by Guido van Rossum.