Various PEPs: fix typos (GH-2211)
Co-authored-by: hauntsaninja <>
This commit is contained in:
parent
989a70412d
commit
ace871d870
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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::
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
||||
==============
|
||||
|
|
|
@ -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%):
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue