Fix typos in PEPs using codespell (#3909)
This commit is contained in:
parent
99e9a5f4b2
commit
89ae6e0e30
|
@ -15,3 +15,7 @@
|
||||||
|
|
||||||
explicitly declared using ``in``, ``out`` and ``inout`` keywords.
|
explicitly declared using ``in``, ``out`` and ``inout`` keywords.
|
||||||
| | | | | | | inout |
|
| | | | | | | inout |
|
||||||
|
|
||||||
|
>>> "abd\
|
||||||
|
|
||||||
|
* ``Is``, ``IsNot``, ``In``, and ``NotIn`` are not supported
|
||||||
|
|
|
@ -6,10 +6,12 @@ arithmetics
|
||||||
asend
|
asend
|
||||||
ba
|
ba
|
||||||
ccompiler
|
ccompiler
|
||||||
|
checkin
|
||||||
clos
|
clos
|
||||||
complies
|
complies
|
||||||
crate
|
crate
|
||||||
dedented
|
dedented
|
||||||
|
discernable
|
||||||
dota
|
dota
|
||||||
extraversion
|
extraversion
|
||||||
falsy
|
falsy
|
||||||
|
@ -18,10 +20,13 @@ groth
|
||||||
iif
|
iif
|
||||||
implementor
|
implementor
|
||||||
implementors
|
implementors
|
||||||
|
loath
|
||||||
nd
|
nd
|
||||||
ned
|
ned
|
||||||
re-usable
|
re-usable
|
||||||
re-use
|
re-use
|
||||||
|
re-used
|
||||||
|
re-using
|
||||||
recuse
|
recuse
|
||||||
reenable
|
reenable
|
||||||
referencable
|
referencable
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
[codespell]
|
[codespell]
|
||||||
skip = ./.git
|
skip = ./.git,./.codespellrc,./build,./ruff_cache,./.venv
|
||||||
ignore-words = .codespell/ignore-words.txt
|
ignore-words = .codespell/ignore-words.txt
|
||||||
exclude-file = .codespell/exclude-file.txt
|
exclude-file = .codespell/exclude-file.txt
|
||||||
uri-ignore-words-list = daa,ist,searchin,theses
|
uri-ignore-words-list = daa,ist,searchin,theses
|
||||||
|
|
|
@ -789,7 +789,7 @@ raw Unicode UTF-16 data (which the ``bf_getreadbuf`` returns), but
|
||||||
instead tries to encode the Unicode object using the default
|
instead tries to encode the Unicode object using the default
|
||||||
encoding and then returns a pointer to the resulting string object
|
encoding and then returns a pointer to the resulting string object
|
||||||
(or raises an exception in case the conversion fails). This was
|
(or raises an exception in case the conversion fails). This was
|
||||||
done in order to prevent accidentely writing binary data to an
|
done in order to prevent accidentally writing binary data to an
|
||||||
output stream which the other end might not recognize.
|
output stream which the other end might not recognize.
|
||||||
|
|
||||||
This has the advantage of being able to write to output streams
|
This has the advantage of being able to write to output streams
|
||||||
|
|
|
@ -75,7 +75,7 @@ ActionScript
|
||||||
------------
|
------------
|
||||||
|
|
||||||
ActionScript__ is a class-based, single inheritance,
|
ActionScript__ is a class-based, single inheritance,
|
||||||
object-oriented superset of ECMAScript. It supports inferfaces and
|
object-oriented superset of ECMAScript. It supports interfaces and
|
||||||
strong runtime-checked static typing. Compilation supports a “strict
|
strong runtime-checked static typing. Compilation supports a “strict
|
||||||
dialect” where type mismatches are reported at compile-time.
|
dialect” where type mismatches are reported at compile-time.
|
||||||
|
|
||||||
|
|
|
@ -654,7 +654,7 @@ dynamic strings incorrectly. This requires a user to actually run a static analy
|
||||||
|
|
||||||
If :pep:`675` tells you that you are violating a type check, it is up to the programmer to know how to handle the dynamic-ness of the string.
|
If :pep:`675` tells you that you are violating a type check, it is up to the programmer to know how to handle the dynamic-ness of the string.
|
||||||
This PEP provides a safer alternative to f-strings at runtime.
|
This PEP provides a safer alternative to f-strings at runtime.
|
||||||
If a user recieves a type-error, changing an existing f-string into a t-string could be an easy way to solve the problem.
|
If a user receives a type-error, changing an existing f-string into a t-string could be an easy way to solve the problem.
|
||||||
|
|
||||||
t-strings enable safer code by correctly escaping the dynamic sections of strings, while maintaining the static portions.
|
t-strings enable safer code by correctly escaping the dynamic sections of strings, while maintaining the static portions.
|
||||||
|
|
||||||
|
|
|
@ -66,8 +66,8 @@ simply that the locale is frequently misconfigured. An obvious solution
|
||||||
suggests itself: ignore the locale encoding and use UTF-8.
|
suggests itself: ignore the locale encoding and use UTF-8.
|
||||||
|
|
||||||
|
|
||||||
Passthough for undecodable bytes: surrogateescape
|
Passthrough for undecodable bytes: surrogateescape
|
||||||
-------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
||||||
When decoding bytes from UTF-8 using the default ``strict`` error
|
When decoding bytes from UTF-8 using the default ``strict`` error
|
||||||
handler, Python 3 raises a ``UnicodeDecodeError`` on the first
|
handler, Python 3 raises a ``UnicodeDecodeError`` on the first
|
||||||
|
|
|
@ -233,7 +233,7 @@ significant issue, as it is unlikely that anyone would be able to write to
|
||||||
|
|
||||||
For a ``__pypackages__`` directory in the current working directory, the
|
For a ``__pypackages__`` directory in the current working directory, the
|
||||||
interactive interpreter could be affected. However, this is not significantly
|
interactive interpreter could be affected. However, this is not significantly
|
||||||
different than the existing issue of someone having a ``math.py`` mdule in their
|
different than the existing issue of someone having a ``math.py`` module in their
|
||||||
current directory, and while (just like that case) it can cause user confusion,
|
current directory, and while (just like that case) it can cause user confusion,
|
||||||
it does not introduce any new security implications.
|
it does not introduce any new security implications.
|
||||||
|
|
||||||
|
|
|
@ -117,7 +117,7 @@ more incompatible changes. The technical debt only steadily
|
||||||
increases over time.
|
increases over time.
|
||||||
|
|
||||||
With backward compatibility, it becomes possible to upgrade Python
|
With backward compatibility, it becomes possible to upgrade Python
|
||||||
increamentally in a project, without having to fix all of the issues at once.
|
incrementally in a project, without having to fix all of the issues at once.
|
||||||
|
|
||||||
The "all-or-nothing" is a showstopper to port large Python 2 code bases
|
The "all-or-nothing" is a showstopper to port large Python 2 code bases
|
||||||
to Python 3. The list of incompatible changes between Python 2 and
|
to Python 3. The list of incompatible changes between Python 2 and
|
||||||
|
|
|
@ -31,7 +31,7 @@ generated for all lines of code, and only for actual code.
|
||||||
They should also be able to assume that the line number in ``f_lineno`` is correct.
|
They should also be able to assume that the line number in ``f_lineno`` is correct.
|
||||||
|
|
||||||
The current implementation mostly does this, but fails in a few cases.
|
The current implementation mostly does this, but fails in a few cases.
|
||||||
This requires workarounds in tooling and is a nuisance for alternative Python implementions.
|
This requires workarounds in tooling and is a nuisance for alternative Python implementations.
|
||||||
|
|
||||||
Having this guarantee also benefits implementers of CPython in the long term, as the current behaviour is not obvious and has some odd corner cases.
|
Having this guarantee also benefits implementers of CPython in the long term, as the current behaviour is not obvious and has some odd corner cases.
|
||||||
|
|
||||||
|
|
|
@ -812,7 +812,7 @@ in a :ref:`separate page <639-rejected-ideas-details>`.
|
||||||
Appendices
|
Appendices
|
||||||
==========
|
==========
|
||||||
|
|
||||||
A list of auxilliary documents is provided:
|
A list of auxiliary documents is provided:
|
||||||
|
|
||||||
- Detailed :ref:`Licensing Examples <639-examples>`,
|
- Detailed :ref:`Licensing Examples <639-examples>`,
|
||||||
- :ref:`User Scenarios <639-user-scenarios>`,
|
- :ref:`User Scenarios <639-user-scenarios>`,
|
||||||
|
|
|
@ -250,7 +250,7 @@ approach to specify their license files location. It was pointed out that
|
||||||
it is easily possible to incorrectly assume that paths also support
|
it is easily possible to incorrectly assume that paths also support
|
||||||
globs.
|
globs.
|
||||||
|
|
||||||
Therfore, it was decided against this approach in favor of a flat array value
|
Therefore, it was decided against this approach in favor of a flat array value
|
||||||
which simplifies the specification and implementation,
|
which simplifies the specification and implementation,
|
||||||
and more closely matches the configuration format of existing tools.
|
and more closely matches the configuration format of existing tools.
|
||||||
The PEP recommends not to use other than alphanumerical symbols and dot
|
The PEP recommends not to use other than alphanumerical symbols and dot
|
||||||
|
|
|
@ -421,7 +421,7 @@ It will be an error to *not* use ``Py_RELATIVE_OFFSET`` with negative
|
||||||
``PyMember_SetOne``).
|
``PyMember_SetOne``).
|
||||||
|
|
||||||
CPython will adjust the offset and clear the ``Py_RELATIVE_OFFSET`` flag when
|
CPython will adjust the offset and clear the ``Py_RELATIVE_OFFSET`` flag when
|
||||||
intitializing a type.
|
initializing a type.
|
||||||
This means that:
|
This means that:
|
||||||
|
|
||||||
* the created type's ``tp_members`` will not match the input
|
* the created type's ``tp_members`` will not match the input
|
||||||
|
|
|
@ -173,7 +173,7 @@ user-defined type guard function changes in two ways.
|
||||||
reveal_type(direction) # "Literal[NW]"
|
reveal_type(direction) # "Literal[NW]"
|
||||||
|
|
||||||
|
|
||||||
The type-theoretic rules for type narrowing are specificed in the following
|
The type-theoretic rules for type narrowing are specified in the following
|
||||||
table.
|
table.
|
||||||
|
|
||||||
============ ======================= ===================
|
============ ======================= ===================
|
||||||
|
@ -267,7 +267,7 @@ behavior. Such type guard functions could break with the new behavior.
|
||||||
# "str", which is perhaps not what was intended.
|
# "str", which is perhaps not what was intended.
|
||||||
reveal_type(val)
|
reveal_type(val)
|
||||||
|
|
||||||
We think it is unlikley that such user-defined type guards exist in real-world
|
We think it is unlikely that such user-defined type guards exist in real-world
|
||||||
code. The mypy primer results didn't uncover any such cases.
|
code. The mypy primer results didn't uncover any such cases.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -554,7 +554,7 @@ One of the main requests in the discussion of this PEP was the inclusion of
|
||||||
other kind of information, such as the ``site-packages`` path. It is the opinion
|
other kind of information, such as the ``site-packages`` path. It is the opinion
|
||||||
of the PEP author that information regarding the Python environment should be
|
of the PEP author that information regarding the Python environment should be
|
||||||
provided by a separate file, creating the a clear separation between the build
|
provided by a separate file, creating the a clear separation between the build
|
||||||
details, which should be immutable accross any interpreter instance, and details
|
details, which should be immutable across any interpreter instance, and details
|
||||||
that can change, such as environment details.
|
that can change, such as environment details.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -982,7 +982,7 @@ any proposal to add a granular initialization API around phases is
|
||||||
effectively the opposite of what this PEP is trying to accomplish.
|
effectively the opposite of what this PEP is trying to accomplish.
|
||||||
Such API is more complicated, it requires adding new public structures
|
Such API is more complicated, it requires adding new public structures
|
||||||
and new public functions. It makes the Python initialization more
|
and new public functions. It makes the Python initialization more
|
||||||
complicated, rather than this PEP tries to unifiy existing APIs and make
|
complicated, rather than this PEP tries to unify existing APIs and make
|
||||||
them simpler (the opposite). Having multiple structures for similar
|
them simpler (the opposite). Having multiple structures for similar
|
||||||
purpose can lead to duplicate members, similar issue than duplicated
|
purpose can lead to duplicate members, similar issue than duplicated
|
||||||
members between existing ``PyPreConfig`` and ``PyConfig`` structures.
|
members between existing ``PyPreConfig`` and ``PyConfig`` structures.
|
||||||
|
|
|
@ -340,7 +340,7 @@ Choose the sections that best describe you:
|
||||||
|
|
||||||
- ...in general, the JIT shouldn't be much of an inconvenience to you
|
- ...in general, the JIT shouldn't be much of an inconvenience to you
|
||||||
(depending on what you're trying to do). The micro-op interpreter isn't
|
(depending on what you're trying to do). The micro-op interpreter isn't
|
||||||
going anywhere, and still offers a debugging experience similer to what
|
going anywhere, and still offers a debugging experience similar to what
|
||||||
the main bytecode interpreter provides today. There is moderate likelihood
|
the main bytecode interpreter provides today. There is moderate likelihood
|
||||||
that larger changes to the interpreter (such as adding new local
|
that larger changes to the interpreter (such as adding new local
|
||||||
variables, changing error handling and deoptimization logic, or changing
|
variables, changing error handling and deoptimization logic, or changing
|
||||||
|
|
|
@ -1024,7 +1024,7 @@ as an implicit ``TypeExpr`` value and be used directly in a context where a
|
||||||
``TypeExpr`` was expected. However making that possible would require making
|
``TypeExpr`` was expected. However making that possible would require making
|
||||||
changes to the rules that type checkers use for the ``|`` operator. These rules
|
changes to the rules that type checkers use for the ``|`` operator. These rules
|
||||||
are currently underspecified and would need to be make explicit first,
|
are currently underspecified and would need to be make explicit first,
|
||||||
before making changes to them. The PEP author is not sufficently motivated to
|
before making changes to them. The PEP author is not sufficiently motivated to
|
||||||
take on that specification work at the time of writing.
|
take on that specification work at the time of writing.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -440,7 +440,7 @@ unless otherwise specified for the same reason.
|
||||||
- Tables can be written inline.
|
- Tables can be written inline.
|
||||||
- Represents the files to potentially install for the package and version.
|
- Represents the files to potentially install for the package and version.
|
||||||
- Entries in ``[[packages.files]]`` SHOULD be lexicographically sorted by
|
- Entries in ``[[packages.files]]`` SHOULD be lexicographically sorted by
|
||||||
``packages.files.name`` key to minimze changes in diffs.
|
``packages.files.name`` key to minimize changes in diffs.
|
||||||
|
|
||||||
|
|
||||||
``packages.files.name``
|
``packages.files.name``
|
||||||
|
|
|
@ -132,7 +132,7 @@ The PEP author presents the PEP and the vote results to the Council of Elders.
|
||||||
The council ponders two things:
|
The council ponders two things:
|
||||||
|
|
||||||
- the PEP gravity and its implications,
|
- the PEP gravity and its implications,
|
||||||
- the measureable vote results (how many people voted, which individuals voted, what they voted).
|
- the measurable vote results (how many people voted, which individuals voted, what they voted).
|
||||||
|
|
||||||
They pronounce a tentative decision on whether the vote passed and this decision is published.
|
They pronounce a tentative decision on whether the vote passed and this decision is published.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue