Various PEPs: fix typos (GH-2211)

Co-authored-by: hauntsaninja <>
This commit is contained in:
Shantanu 2022-01-03 23:01:23 -06:00 committed by GitHub
parent 989a70412d
commit ace871d870
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 16 additions and 16 deletions

View File

@ -218,13 +218,13 @@ No-longer-supported platforms
* | Name: AtheOS
| Unsupported in: Python 2.6 (with "AtheOS" changed to "Syllable")
| Build broken in: Python 2.7 (edit configure to reenable)
| Build broken in: Python 2.7 (edit configure to re-enable)
| Code removed in: Python 3.0
| Details: http://www.syllable.org/discussion.php?id=2320
* | Name: BeOS
| Unsupported in: Python 2.6 (warning in configure)
| Build broken in: Python 2.7 (edit configure to reenable)
| Build broken in: Python 2.7 (edit configure to re-enable)
| Code removed in: Python 3.0
* | Name: Systems using Mach C Threads

View File

@ -78,7 +78,7 @@ To be defensive, the following code should be used::
``str.format()`` was added to address some of these problems with
%-formatting. In particular, it uses normal function call syntax (and
therefor supports multiple parameters) and it is extensible through
therefore supports multiple parameters) and it is extensible through
the ``__format__()`` method on the object being converted to a
string. See PEP 3101 for a detailed rationale. This PEP reuses much of
the ``str.format()`` syntax and machinery, in order to provide

View File

@ -522,7 +522,7 @@ This query API allows extension module code to determine the potential impact
of mutating the mapping returned by ``PyLocals_Get()`` without needing access
to the details of the running frame object. Python code gets equivalent
information visually through lexical scoping (as covered in the new ``locals()``
builtin documention).
builtin documentation).
To allow extension module code to behave consistently regardless of the active
Python scope, the stable C ABI would gain the following new function::

View File

@ -24,7 +24,7 @@ with `license expression strings <Add License-Expression field_>`_ using
`SPDX identifiers <#spdxid_>`_ in a new ``License-Expression`` field.
This will make license declarations simpler and less ambiguous for
package authors to create, end users to read and understand, and
tools to programatically process.
tools to programmatically process.
The PEP also:
@ -1301,7 +1301,7 @@ Don't mandate validating new fields on PyPI
Previously, while this PEP did include normative guidelines for packaging
publishing tools (such as Twine), it did not provide specific guidance
for PyPI (or other package indicies) as to whether and how they
for PyPI (or other package indices) as to whether and how they
should validate the ``License-Expression`` or ``License-File`` fields,
nor how they should handle using them in combination with the deprecated
``License`` field or license classifiers. This simplifies the specification

View File

@ -440,7 +440,7 @@ A string representing a URL where to get the file.
The installer MAY support any schemes it wants for URLs. A URL with no
scheme MUST be assumed to be a local file path (both relative paths to
the lock file and absolute paths). Installers MUST support, at
minumum, HTTPS URLs as well as local file paths.
minimum, HTTPS URLs as well as local file paths.
An installer MAY choose to not use the URL to retrieve a file
if a file matching the specified hash can be found using alternative
@ -767,10 +767,10 @@ files.
Reference Implementation
========================
I proof-of-concept locker can be found at
https://github.com/frostming/pep665_poc . Not installer has been
A proof-of-concept locker can be found at
https://github.com/frostming/pep665_poc . No installer has been
implemented yet, but the design of this PEP suggests the locker is the
more difficult asepect to implment.
more difficult aspect to implement.
==============

View File

@ -37,7 +37,7 @@ Using a macro as a l-value
In the Python C API, some functions are implemented as macro because
writing a macro is simpler than writing a regular function. If a macro
exposes directly a struture member, it is technically possible to use
exposes directly a structure member, it is technically possible to use
this macro to not only get the structure member but also set it.
Example with the Python 3.10 ``Py_TYPE()`` macro::
@ -250,7 +250,7 @@ Backwards Compatibility
The proposed C API changes are backward incompatible on purpose.
At December 1, 2021, a code search on the PyPI top 5000 projects (4760
projects in practice, others don't have a source achive) found that
projects in practice, others don't have a source archive) found that
`only 14 projects are affected
<https://bugs.python.org/issue45476#msg407456>`_ (0.3%):

View File

@ -122,13 +122,13 @@ The following redirect rules must be created from the `python.org`_ domain:
}
Redirects must be implemented to preserve `URL fragments`_ for backward
compatability purposes.
compatibility purposes.
Backwards Compatibility
=======================
Due to server-side redirects to new canonical URLs, there are no backwards
compatability concerns. Links in previously published materials referring to
compatibility concerns. Links in previously published materials referring to
any old URL scheme will be guaranteed to work.
Security Implications

View File

@ -72,7 +72,7 @@ There are a few usability challenges with ``Callable`` we can see here:
- It is verbose, particularly for more complex function signatures.
- It relies on two levels of nested brackets, unlike any other generic
type. This can be expecially hard to read when some of the type
type. This can be especially hard to read when some of the type
parameters are themselves generic types.
- The bracket structure is not visually similar to how function signatures
are written.

View File

@ -124,7 +124,7 @@ adopted. At the time, Guido's response was:
This is dangerously close to introducing CSNS [classic static
nested scopes]. *If* you were to do so, your proposed semantics
of scoped seem allright. I still think there is not enough need
of scoped seem alright. I still think there is not enough need
for CSNS to warrant this kind of construct ...
After PEP 227, the "outer name rebinding discussion" has reappeared