From cfb7bd74dba6357a73be1f1e0614a1a3cc6b69cb Mon Sep 17 00:00:00 2001 From: Min ho Kim Date: Thu, 4 Jul 2019 04:20:45 +1000 Subject: [PATCH] Fix typos (#1113) --- pep-0101.txt | 24 ++++++++++++------------ pep-0201.txt | 2 +- pep-0205.txt | 2 +- pep-0207.txt | 2 +- pep-0224.txt | 2 +- pep-0236.txt | 4 ++-- pep-0245.txt | 4 ++-- pep-0266.txt | 2 +- pep-0275.txt | 4 ++-- pep-0280.txt | 2 +- pep-0304.txt | 2 +- pep-0319.txt | 4 ++-- pep-0327.txt | 2 +- pep-0333.txt | 2 +- pep-0336.txt | 2 +- pep-0345.txt | 2 +- pep-0353.txt | 2 +- pep-0359.txt | 2 +- pep-0369.txt | 2 +- pep-0370.txt | 2 +- pep-0378.txt | 2 +- pep-0381.txt | 4 ++-- pep-0382.txt | 4 ++-- pep-0406.txt | 2 +- pep-0416.txt | 4 ++-- pep-0418.txt | 2 +- pep-0423.txt | 2 +- pep-0425.txt | 2 +- pep-0426.txt | 2 +- pep-0432.txt | 4 ++-- pep-0435.txt | 2 +- pep-0440.txt | 4 ++-- pep-0444.txt | 2 +- pep-0447.txt | 6 +++--- pep-0451.txt | 2 +- pep-0456.txt | 4 ++-- pep-0458.txt | 2 +- pep-0473.txt | 2 +- pep-0493.txt | 2 +- pep-0500.txt | 2 +- pep-0504.txt | 6 +++--- pep-0505.rst | 2 +- pep-0508.txt | 2 +- pep-0509.txt | 2 +- pep-0517.txt | 2 +- pep-0518.txt | 8 ++++---- pep-0519.txt | 2 +- pep-0520.txt | 2 +- pep-0521.txt | 2 +- pep-0524.txt | 8 ++++---- pep-0532.txt | 2 +- pep-0533.txt | 2 +- pep-0538.txt | 2 +- pep-0539.txt | 2 +- pep-0543.rst | 2 +- pep-0545.txt | 2 +- pep-0554.rst | 4 ++-- pep-0557.rst | 2 +- pep-0563.rst | 4 ++-- pep-0571.rst | 2 +- pep-0573.rst | 2 +- pep-0574.rst | 2 +- pep-0575.rst | 2 +- pep-0576.rst | 2 +- pep-0577.rst | 2 +- pep-0582.rst | 2 +- pep-0587.rst | 4 ++-- pep-0590.rst | 2 +- pep-0591.rst | 2 +- pep-0592.rst | 2 +- pep-0595.rst | 4 ++-- pep-0597.rst | 2 +- pep-0598.rst | 2 +- pep-0628.txt | 2 +- pep-3103.txt | 4 ++-- pep-3108.txt | 2 +- pep-3118.txt | 2 +- pep-3137.txt | 2 +- pep-3138.txt | 2 +- pep-3150.txt | 2 +- pep-3151.txt | 2 +- pep-3333.txt | 2 +- pep-8001.rst | 2 +- pep-8002.rst | 6 +++--- pep-8012.rst | 2 +- pep-8014.rst | 6 +++--- 86 files changed, 126 insertions(+), 126 deletions(-) diff --git a/pep-0101.txt b/pep-0101.txt index 4ea1c133f..41109e5ff 100644 --- a/pep-0101.txt +++ b/pep-0101.txt @@ -534,20 +534,20 @@ the main repo. # **new branch** release, i.e. alphas and first beta # do a checkout of the master branch $ git checkout master - + # 2. Else, for all other releases, checkout the # appropriate release branch. $ git checkout X.Y - + # Fetch the newly created and signed tag from your clone repo $ git fetch --tags git@github.com:your-github-id/cpython.git vX.Y.ZaN - # Merge the temporary release engineering branch back into + # Merge the temporary release engineering branch back into $ git merge --no-squash vX.Y.ZaN $ git commit -m 'Merge release engineering branch' - If this is a **new branch** release, i.e. first beta, now create the new release branch:: - + $ git checkout -b X.Y - For *all* releases, do the guided post-release steps with the @@ -556,7 +556,7 @@ the main repo. $ .../release-tools/release.py --done X.Y.ZaN - Review and commit these changes:: - + $ git commit -m 'Post release updates' - If this is a **new branch** release (e.g. the first beta), @@ -612,13 +612,13 @@ the main repo. - Commit and push to the main repo.:: # Do a dry run first. - + # For feature pre-releases prior to a **new branch** release, # i.e. a feature alpha release: $ git push --dry-run --tags git@github.com:python/cpython.git master # If it looks OK, take the plunge. There's no going back! $ git push --tags git@github.com:python/cpython.git master - + # For a **new branch** release, i.e. first beta: $ git push --dry-run --tags git@github.com:python/cpython.git X.Y $ git push --dry-run --tags git@github.com:python/cpython.git master @@ -635,10 +635,10 @@ the main repo. for the newly created branch (X.Y). Look at the values for the previous release branch (X.Y-1) and use them as a template. https://github.com/python/cpython/settings/branches/ - + Also, add a ``needs backport to X.Y`` label to the Github repo. https://github.com/python/cpython/labels - + - For all releases, if you made temporary changes to the permissions for the branch on GitHub, undo those temporary changes now. https://github.com/python/cpython/settings/branches/ @@ -660,7 +660,7 @@ at the moment, sorry. To do these steps, you must have the permission to edit the website. If you don't have that, ask someone on pydotorg@python.org for the proper -permissions. (Or ask Ewa, who coordinated the effort for the new newbsite +permissions. (Or ask Ewa, who coordinated the effort for the new website with RevSys.) - Log in to https://www.python.org/admin . @@ -809,7 +809,7 @@ with RevSys.) - If this is a **new branch** release, you will need to ensure various pieces of the development infrastructure are updated for the new branch. These include: - + - Update the devguide to reflect the new branches and versions. - Ensure buildbots are defined for the new branch (contact zware). @@ -831,7 +831,7 @@ with RevSys.) branches and that the release branch is properly protected (no direct pushes, etc). - - Verify that the on-line docs are building properly (this may take up to + - Verify that the on-line docs are building properly (this may take up to 24 hours for a complete build on the web site). diff --git a/pep-0201.txt b/pep-0201.txt index 31db8da20..9675bc662 100644 --- a/pep-0201.txt +++ b/pep-0201.txt @@ -281,7 +281,7 @@ References .. [2] http://www.haskell.org/onlinereport/standard-prelude.html#$vzip -Greg Wilson's questionaire on proposed syntax to some CS grad students +Greg Wilson's questionnaire on proposed syntax to some CS grad students http://www.python.org/pipermail/python-dev/2000-July/013139.html diff --git a/pep-0205.txt b/pep-0205.txt index e3d1a0eea..3aeb888f1 100644 --- a/pep-0205.txt +++ b/pep-0205.txt @@ -125,7 +125,7 @@ underlying object, and proxy objects which masquerade as the original objects as much as possible. Reference objects are easy to work with when some additional layer -of object managemenet is being added in Python; references can be +of object management is being added in Python; references can be checked for liveness explicitly, without having to invoke operations on the referents and catching some special exception raised when an invalid weak reference is used. diff --git a/pep-0207.txt b/pep-0207.txt index bf963c5b3..b13f121f2 100644 --- a/pep-0207.txt +++ b/pep-0207.txt @@ -90,7 +90,7 @@ Proposed Resolutions 1. Full backwards compatibility can be achieved as follows. When an object defines ``tp_compare()`` but not ``tp_richcompare()``, and a rich comparison is requested, the outcome of ``tp_compare()`` is - used in the ovious way. E.g. if "<" is requested, an exception if + used in the obvious way. E.g. if "<" is requested, an exception if ``tp_compare()`` raises an exception, the outcome is 1 if ``tp_compare()`` is negative, and 0 if it is zero or positive. Etc. diff --git a/pep-0224.txt b/pep-0224.txt index a19a4825b..a208b002a 100644 --- a/pep-0224.txt +++ b/pep-0224.txt @@ -160,7 +160,7 @@ The trailing slash would cause the Python compiler to concatenate the attribute value and the docstring. A modern syntax highlighting editor would easily make this -accident visible, though, and by simply inserting emtpy lines +accident visible, though, and by simply inserting empty lines between the attribute definition and the docstring you can avoid the possible concatenation completely, so the problem is negligible. diff --git a/pep-0236.txt b/pep-0236.txt index c19bab14a..9cc4d3b44 100644 --- a/pep-0236.txt +++ b/pep-0236.txt @@ -73,7 +73,7 @@ name ``__future__``:: feature: identifier name: identifier -In addition, all future_statments must appear near the top of the module. The +In addition, all future_statements must appear near the top of the module. The only lines that can appear before a future_statement are: + The module docstring (if any). @@ -167,7 +167,7 @@ Standard Module __future__.py 3. To document when incompatible changes were introduced, and when they will be-- or were --made mandatory. This is a form of executable documentation, - and can be inspected programatically via importing ``__future__`` and + and can be inspected programmatically via importing ``__future__`` and examining its contents. Each statement in ``__future__.py`` is of the form:: diff --git a/pep-0245.txt b/pep-0245.txt index f7669d828..84fac96ed 100644 --- a/pep-0245.txt +++ b/pep-0245.txt @@ -187,7 +187,7 @@ CountFishInterface and ColorFishInterface:: def buySomeFish(quantity=1): "Buy some fish at the market" -The FishMarketInteface extends upon the CountFishInterface and +The FishMarketInterface extends upon the CountFishInterface and ColorfishInterface. @@ -293,7 +293,7 @@ or a tuple of interface assertions. For example:: FooInterface - FooInterface, (BarInteface, BobInterface) + FooInterface, (BarInterface, BobInterface) FooInterface, (BarInterface, (BobInterface, MyClass.__implements__)) diff --git a/pep-0266.txt b/pep-0266.txt index 87e04be9c..7e4901437 100644 --- a/pep-0266.txt +++ b/pep-0266.txt @@ -54,7 +54,7 @@ In an attempt to gauge the effect of this proposal, I modified the Pystone benchmark program included in the Python distribution to cache global functions. Its main function, ``Proc0``, makes calls to ten different functions inside its ``for`` loop. In addition, ``Func2`` calls ``Func1`` -repeatedly inside a loop. If local copies of these 11 global idenfiers are +repeatedly inside a loop. If local copies of these 11 global identifiers are made before the functions' loops are entered, performance on this particular benchmark improves by about two percent (from 5561 pystones to 5685 on my laptop). It gives some indication that performance would be improved by diff --git a/pep-0275.txt b/pep-0275.txt index 0c7d0e82c..f2dae24b0 100644 --- a/pep-0275.txt +++ b/pep-0275.txt @@ -120,7 +120,7 @@ well-known immutable types (strings, unicode, numbers) and use the hash table for finding the right opcode snippet. If this condition is not met, the interpreter should revert to the standard if-elif-else processing by simply skipping the -SWITCH opcode and procedding with the usual if-elif-else byte +SWITCH opcode and proceeding with the usual if-elif-else byte code stream. @@ -129,7 +129,7 @@ Issues: The new optimization should not change the current Python semantics (by reducing the number of ``__cmp__`` calls and adding ``__hash__`` calls in if-elif-else constructs which are affected -by the optimiztation). To assure this, switching can only +by the optimization). To assure this, switching can only safely be implemented either if a "from __future__" style flag is used, or the switching variable is one of the builtin immutable types: int, float, string, unicode, etc. (not diff --git a/pep-0280.txt b/pep-0280.txt index 5f0b35f9c..843d6d8fc 100644 --- a/pep-0280.txt +++ b/pep-0280.txt @@ -312,7 +312,7 @@ Additional Ideas # we're checking the builtin dict for that *now*, this # still works if the builtin first came into existence # after we were constructed. Note too that del on - # namespace dicts is rare, so the expensse of this check + # namespace dicts is rare, so the expense of this check # shouldn't matter. if key in self.basedict: c.objptr = self.basedict[key] diff --git a/pep-0304.txt b/pep-0304.txt index 0e2639fe3..51979da82 100644 --- a/pep-0304.txt +++ b/pep-0304.txt @@ -91,7 +91,7 @@ During import, this extension works as follows: - If no byte-compiled file is found, an attempt to read a byte-compiled file from the augmented directory is made. -- If bytecode generation is required, the generated bytecode is wrtten +- If bytecode generation is required, the generated bytecode is written to the augmented directory if possible. Note that this PEP is explicitly *not* about providing diff --git a/pep-0319.txt b/pep-0319.txt index 6c03e24a8..5e56171b2 100644 --- a/pep-0319.txt +++ b/pep-0319.txt @@ -407,9 +407,9 @@ is equivalent to the proposed:: synchronize the_lock: change_shared_data() -PEP 310 must synchronize on an exsiting lock, while this PEP +PEP 310 must synchronize on an existing lock, while this PEP proposes that unqualified 'synchronize' statements synchronize on -a global, internal, transparent lock in addition to qualifiled +a global, internal, transparent lock in addition to qualified 'synchronize' statements. The 'with' statement also requires lock initialization, while the 'synchronize' statement can synchronize on any target object **including** locks. diff --git a/pep-0327.txt b/pep-0327.txt index b50c3f912..020ad8986 100644 --- a/pep-0327.txt +++ b/pep-0327.txt @@ -418,7 +418,7 @@ incremented by 1 (round toward positive infinity):: ``round-floor``: If all of the discarded digits are zero or if the sign is positive the result is unchanged; otherwise, the absolute value of the result is incremented by 1 (round toward negative -infinty):: +infinity):: 1.123 --> 1.12 1.128 --> 1.12 diff --git a/pep-0333.txt b/pep-0333.txt index 49f0e9dce..44b590774 100644 --- a/pep-0333.txt +++ b/pep-0333.txt @@ -872,7 +872,7 @@ portion of the response that precedes it. In these cases, applications will usually return an iterator (often a generator-iterator) that produces the output in a block-by-block -fashion. These blocks may be broken to coincide with mulitpart +fashion. These blocks may be broken to coincide with multipart boundaries (for "server push"), or just before time-consuming tasks (such as reading another block of an on-disk file). diff --git a/pep-0336.txt b/pep-0336.txt index ced7c200f..e7953211d 100644 --- a/pep-0336.txt +++ b/pep-0336.txt @@ -22,7 +22,7 @@ BDFL Pronouncement This PEP is rejected. It is considered a feature that ``None`` raises an error when called. The proposal falls short in tests for -obviousness, clarity, explictness, and necessity. The provided Switch +obviousness, clarity, explicitness, and necessity. The provided Switch example is nice but easily handled by a simple lambda definition. See python-dev discussion on 17 June 2005 [2]_. diff --git a/pep-0345.txt b/pep-0345.txt index 561d49faf..1f093defc 100644 --- a/pep-0345.txt +++ b/pep-0345.txt @@ -239,7 +239,7 @@ License (optional) Text indicating the license covering the distribution where the license is not a selection from the "License" Trove classifiers. See "Classifier" below. This field may also be used to specify a -particular version of a licencse which is named via the ``Classifier`` +particular version of a license which is named via the ``Classifier`` field, or to indicate a variation or exception to such a license. Examples:: diff --git a/pep-0353.txt b/pep-0353.txt index f9cc08a6f..3d2dcbfad 100644 --- a/pep-0353.txt +++ b/pep-0353.txt @@ -214,7 +214,7 @@ Py_ssize_t is just a typedef for int. On a 64-bit system, the compiler will warn in many places. If these warnings are ignored, the code will continue to work as long as the container sizes don't -exceeed 2**31, i.e. it will work nearly as good as +exceed 2**31, i.e. it will work nearly as good as it does currently. There are two exceptions to this statement: if the extension module implements the sequence protocol, it must be updated, or the calling diff --git a/pep-0359.txt b/pep-0359.txt index b16fcdbba..a2aa6d410 100644 --- a/pep-0359.txt +++ b/pep-0359.txt @@ -472,7 +472,7 @@ equivalent nesting with a much more explicit syntax:: h1.tail = 'after second h1' And if the repetition of the element names here is too much of a DRY -violoation, it is also possible to eliminate all as-clauses except for +violation, it is also possible to eliminate all as-clauses except for the first by adding a few methods to Element. [10]_ So are there real use-cases for executing the block in a dict of a diff --git a/pep-0369.txt b/pep-0369.txt index 9043eade1..6c40112a9 100644 --- a/pep-0369.txt +++ b/pep-0369.txt @@ -133,7 +133,7 @@ The import hook system guarantees certain invariants. XXX Sample Python implementation ---------------------------- -A Python implemenation may look like:: +A Python implementation may look like:: def notify(name): try: diff --git a/pep-0370.txt b/pep-0370.txt index 13bc1ce34..84b422597 100644 --- a/pep-0370.txt +++ b/pep-0370.txt @@ -163,7 +163,7 @@ directories are created on demand. ``distutils.command.build_ext`` (setup.py build_ext) gets a new argument ``--user`` which adds the include/ and lib/ directories in the user base -dirctory to the search paths for header files and libraries. It also +directory to the search paths for header files and libraries. It also adds the lib/ directory to rpath. The ``site`` module gets two arguments ``--user-base`` and ``--user-site`` diff --git a/pep-0378.txt b/pep-0378.txt index 0e50044e1..01a6b76c8 100644 --- a/pep-0378.txt +++ b/pep-0378.txt @@ -229,7 +229,7 @@ Commentary ten-thousands. Eric Smith pointed-out that these are already handled by the "n" specifier in the locale module (albeit only for integers). This PEP does not attempt to support all of those - possibilities. It focues on a single, relatively common grouping + possibilities. It focuses on a single, relatively common grouping convention that offers a quick way to improve readability in many (though not all) contexts. diff --git a/pep-0381.txt b/pep-0381.txt index 0e6bdad67..9ee24245e 100644 --- a/pep-0381.txt +++ b/pep-0381.txt @@ -87,7 +87,7 @@ PyPI provides statistics on downloads at `/stats`. This page is calculated daily by PyPI, by reading all mirrors' local stats and summing them. -The stats are presented in daily or montly files, under `/stats/days` +The stats are presented in daily or monthly files, under `/stats/days` and `/stats/months`. Each file is a `bzip2` file with these formats: - YYYY-MM-DD.bz2 for daily files @@ -290,7 +290,7 @@ Clients that are browsing PyPI should be able to use a fail-over mechanism when PyPI or the used mirror is not responding. It is up to the client to decide wich mirror should be used, maybe by -looking at its geographical location and its responsivness. +looking at its geographical location and its responsiveness. This PEP does not describe how this fail-over mechanism should work, but it is strongly encouraged that the clients try to use the nearest diff --git a/pep-0382.txt b/pep-0382.txt index 4ac4e3841..bc18474e6 100644 --- a/pep-0382.txt +++ b/pep-0382.txt @@ -175,7 +175,7 @@ extensions related to Python should start with ``.py``. Therefore, the marker file was renamed to be ``.pyp``. Dinu Gherman then observed that using a marker file is not necessary, -and that a directoy extension could well serve as a such as a +and that a directory extension could well serve as a such as a marker. This is what this PEP currently proposes. Phillip Eby designed PEP 402 as an alternative approach to this PEP, @@ -183,7 +183,7 @@ after comparing Python's package syntax with that found in other languages. PEP 402 proposes not to use a marker file at all. At the discussion at PyCon DE 2011, people remarked that having an explicit declaration of a directory as contributing to a package is a desirable -property, rather than an obstactle. In particular, Jython developers +property, rather than an obstacle. In particular, Jython developers noticed that Jython could easily mistake a directory that is a Java package as being a Python package, if there is no need to declare Python packages. diff --git a/pep-0406.txt b/pep-0406.txt index 07d2fc1a1..6dbee7c86 100644 --- a/pep-0406.txt +++ b/pep-0406.txt @@ -256,7 +256,7 @@ References .. [3] Importlib documentation, Cannon (http://docs.python.org/dev/library/importlib) -.. [4] Reference implentation +.. [4] Reference implementation (https://bitbucket.org/jergosh/gsoc_import_engine/src/default/Lib/importlib/engine.py) diff --git a/pep-0416.txt b/pep-0416.txt index 7839ea7c7..2261fa0a5 100644 --- a/pep-0416.txt +++ b/pep-0416.txt @@ -185,14 +185,14 @@ Blacklist approach: inherit from dict and override write methods to raise an exception. It is not truly read-only: it is still possible to call dict methods on such "frozen dictionary" to modify it. -* brownie: `brownie.datastructures.ImmuatableDict +* brownie: `brownie.datastructures.ImmutableDict `_. It is hashable if keys and values are hashable. werkzeug project has the same code: `werkzeug.datastructures.ImmutableDict `_. ImmutableDict is used for global constant (configuration options). The Flask project uses ImmutableDict of werkzeug for its default configuration. -* SQLAchemy project: `sqlachemy.util.immutabledict +* SQLAlchemy project: `sqlalchemy.util.immutabledict `_. It is not hashable and has an extra method: union(). immutabledict is used for the default value of parameter of some functions expecting a mapping. diff --git a/pep-0418.txt b/pep-0418.txt index 01f604568..701832143 100644 --- a/pep-0418.txt +++ b/pep-0418.txt @@ -81,7 +81,7 @@ Limitations: documentation of new functions. The behaviour depends on the operating system: see the `Monotonic Clocks`_ section below. Some recent operating systems provide two clocks, one including time - elapsed during system suspsend, one not including this time. Most + elapsed during system suspend, one not including this time. Most operating systems only provide one kind of clock. * time.monotonic() and time.perf_counter() may or may not be adjusted. For example, ``CLOCK_MONOTONIC`` is slewed on Linux, whereas diff --git a/pep-0423.txt b/pep-0423.txt index 966b51cc4..17710f55a 100644 --- a/pep-0423.txt +++ b/pep-0423.txt @@ -149,7 +149,7 @@ Ownership could be: * `zest.releaser`_ is owned and maintained by Zest Software. * `Django`_ is owned and maintained by the Django Software - Fundation. + Foundation. * a group or community. Example: `sphinx`_ is maintained by developers of the Sphinx diff --git a/pep-0425.txt b/pep-0425.txt index 7d94cc7f7..8044eb56a 100644 --- a/pep-0425.txt +++ b/pep-0425.txt @@ -262,7 +262,7 @@ Why didn't you mention my favorite Python implementation? Why is the ABI tag (the second tag) sometimes "none" in the reference implementation? Since Python 2 does not have an easy way to get to the SOABI (the concept comes from newer versions of Python 3) the reference - implentation at the time of writing guesses "none". Ideally it + implementation at the time of writing guesses "none". Ideally it would detect "py27(d|m|u)" analogous to newer versions of Python, but in the meantime "none" is a good enough way to say "don't know". diff --git a/pep-0426.txt b/pep-0426.txt index 576f01334..5b50aa618 100644 --- a/pep-0426.txt +++ b/pep-0426.txt @@ -1029,7 +1029,7 @@ If the standard ``alldev`` extra has no explicitly declared entries, then integration tools SHOULD implicitly define it as a dependency on the standard ``test``, ``build``, ``doc``, and ``dev`` extras. -The full set of dependency requirements is then based on the uncondtional +The full set of dependency requirements is then based on the unconditional dependencies, along with those of any requested extras. Dependency examples (showing just the ``requires`` subfield):: diff --git a/pep-0432.txt b/pep-0432.txt index 540c3f50a..ce25ee70f 100644 --- a/pep-0432.txt +++ b/pep-0432.txt @@ -406,7 +406,7 @@ initialization from main interpreter initialization. Uninitialized State ------------------- -The unitialized state is where an embedding application determines the settings +The uninitialized state is where an embedding application determines the settings which are required in order to be able to correctly pass configurations settings to the embedded Python runtime. @@ -421,7 +421,7 @@ started the initialization process:: int Py_IsInitializing(); -The query for a completely unitialized environment would then be +The query for a completely uninitialized environment would then be ``!(Py_Initialized() || Py_Initializing())``. diff --git a/pep-0435.txt b/pep-0435.txt index 1fe5341df..7be8daad9 100644 --- a/pep-0435.txt +++ b/pep-0435.txt @@ -45,7 +45,7 @@ to integers is semantically meaningful. For most uses of enumerations, it's a **feature** to reject comparison to integers; enums that compare to integers lead, through transitivity, to comparisons between enums of unrelated types, which isn't desirable in most cases. For some uses, however, greater -interoperatiliby with integers is desired. For instance, this is the case for +interoperability with integers is desired. For instance, this is the case for replacing existing standard library constants (such as ``socket.AF_INET``) with enumerations. diff --git a/pep-0440.txt b/pep-0440.txt index fd45174da..c62aadf73 100644 --- a/pep-0440.txt +++ b/pep-0440.txt @@ -920,7 +920,7 @@ following clauses would match or not as shown:: == 1.1a1 # Equal, so 1.1a1 matches clause == 1.1.* # Same prefix, so 1.1a1 matches clause -An exact match is also considered a prefix match (this interpreation is +An exact match is also considered a prefix match (this interpretation is implied by the usual zero padding rules for the release segment of version identifiers). Given the version ``1.1``, the following clauses would match or not as shown:: @@ -1537,7 +1537,7 @@ the initial reference implementation was released in setuptools 8.0 and pip * The PEP text and the ``is_canonical`` regex were updated to be explicit that numeric components are specifically required to be represented as - squences of ASCII digits, not arbitrary Unicode [Nd] code points. This + sequences of ASCII digits, not arbitrary Unicode [Nd] code points. This was previously implied by the version parsing regex in Appendix B, but not stated explicitly [10]_. diff --git a/pep-0444.txt b/pep-0444.txt index 6ac0e4700..fc8a6ad43 100644 --- a/pep-0444.txt +++ b/pep-0444.txt @@ -888,7 +888,7 @@ portion of the response that precedes it. In these cases, applications will usually return a ``body`` iterator (often a generator-iterator) that produces the output in a block-by-block fashion. These blocks may be broken to coincide with -mulitpart boundaries (for "server push"), or just before +multipart boundaries (for "server push"), or just before time-consuming tasks (such as reading another block of an on-disk file). diff --git a/pep-0447.txt b/pep-0447.txt index c4e98fc40..6db8cbaa1 100644 --- a/pep-0447.txt +++ b/pep-0447.txt @@ -256,13 +256,13 @@ uppercase versions of names:: return 42 def M(self): - return "fourtytwo" + return "fortytwo" obj = SillyObject() assert obj.m() == "fortytwo" As mentioned earlier in this PEP a more realistic use case of this -functionallity is a ``__getdescriptor__`` method that dynamicly populates the +functionality is a ``__getdescriptor__`` method that dynamically populates the class ``__dict__`` based on attribute access, primarily when it is not possible to reliably keep the class dict in sync with its source, for example because the source used to populate ``__dict__`` is dynamic as well and does @@ -339,7 +339,7 @@ changes to the visible behaviour of the ``object.__getattribute__``. As with a custom ``__getattribute__`` method `dir()`_ might not see all (instance) attributes when using the ``__getdescriptor__()`` method to - dynamicly resolve attributes. + dynamically resolve attributes. The solution for that is quite simple: classes using ``__getdescriptor__`` should also implement `__dir__()`_ if they want full support for the builtin diff --git a/pep-0451.txt b/pep-0451.txt index 57e1267f6..5605ab8f5 100644 --- a/pep-0451.txt +++ b/pep-0451.txt @@ -830,7 +830,7 @@ Other Changes * The various finders and loaders provided by importlib will be updated to comply with this proposal. -* Any other implmentations of or dependencies on the import-related APIs +* Any other implementations of or dependencies on the import-related APIs (particularly finders and loaders) in the stdlib will be likewise adjusted to this PEP. While they should continue to work, any such changes that get missed should be considered bugs for the Python 3.4.x diff --git a/pep-0456.txt b/pep-0456.txt index aed8a3160..9f7a10282 100644 --- a/pep-0456.txt +++ b/pep-0456.txt @@ -478,7 +478,7 @@ bytes_hash() (Objects/bytesobject.c) ``bytes_hash`` uses ``_Py_HashBytes`` to provide the tp_hash slot function for bytes objects. The function will continue to use ``_Py_HashBytes`` -but withoht a type cast. +but without a type cast. memory_hash() (Objects/memoryobject.c) -------------------------------------- @@ -486,7 +486,7 @@ memory_hash() (Objects/memoryobject.c) ``memory_hash`` provides the tp_hash slot function for read-only memory views if the original object is hashable, too. It's the only function that has to support hashing of unaligned memory segments in the future. The -function will continue to use ``_Py_HashBytes`` but withoht a type cast. +function will continue to use ``_Py_HashBytes`` but without a type cast. unicode_hash() (Objects/unicodeobject.c) diff --git a/pep-0458.txt b/pep-0458.txt index 436e04350..e87b4cd80 100644 --- a/pep-0458.txt +++ b/pep-0458.txt @@ -1005,7 +1005,7 @@ in download links. __ http://www.python.org/dev/peps/pep-0470/ -Potentional approaches that PyPI administrators MAY consider to handle +Potential approaches that PyPI administrators MAY consider to handle projects hosted externally: 1. Download external distributions but do not verify them. The targets diff --git a/pep-0473.txt b/pep-0473.txt index 61607e2a0..d3829d5c9 100644 --- a/pep-0473.txt +++ b/pep-0473.txt @@ -243,7 +243,7 @@ References .. [3] Enhance exceptions by attaching some more information to them (https://mail.python.org/pipermail/python-ideas/2014-February/025601.html) -.. [4] Specifity in AttributeError +.. [4] Specificity in AttributeError (https://mail.python.org/pipermail/python-ideas/2013-April/020308.html) .. [5] Add an 'attr' attribute to AttributeError diff --git a/pep-0493.txt b/pep-0493.txt index 47c0e1dfe..5947180ad 100644 --- a/pep-0493.txt +++ b/pep-0493.txt @@ -71,7 +71,7 @@ than the standard one provided by consuming upstream CPython 2.7 releases directly, but other potential challenges have also been pointed out with updating embedded Python runtimes and other user level installations of Python. -Rather than allowing a plethora of mutually incompatibile migration techniques +Rather than allowing a plethora of mutually incompatible migration techniques to bloom, this PEP proposes an additional feature to be added to Python 2.7.12 to make it easier to revert a process to the past behaviour of skipping certificate validation in HTTPS client modules. It also provides additional diff --git a/pep-0500.txt b/pep-0500.txt index 6f422834a..947a41e8c 100644 --- a/pep-0500.txt +++ b/pep-0500.txt @@ -64,7 +64,7 @@ Subtraction of datetime A ``tzinfo`` subclass supporting the PDDM, may define a method called ``__datetime_diff__`` that should take two ``datetime.datetime`` instances and return a ``datetime.timedelta`` instance representing -the time elapced from the time represented by the first datetime +the time elapsed from the time represented by the first datetime instance to another. diff --git a/pep-0504.txt b/pep-0504.txt index 9b7dbb667..a1317b589 100644 --- a/pep-0504.txt +++ b/pep-0504.txt @@ -181,9 +181,9 @@ identifiable information [#breaches]_, as well as with failures to take security considerations into account when new systems, like motor vehicles [#uconnect]_, are connected to the internet. It's also the case that a lot of the programming advice readily available on the internet [#search] simply -doesn't take the mathemetical arcana of computer security into account. +doesn't take the mathematical arcana of computer security into account. Compounding these issues is the fact that defenders have to cover *all* of -their potential vulnerabilites, as a single mistake can make it possible to +their potential vulnerabilities, as a single mistake can make it possible to subvert other defences [#bcrypt]_. One of the factors that contributes to making this last aspect particularly @@ -275,7 +275,7 @@ Using first DeprecationWarning, and then eventually a RuntimeWarning, to advise against implicitly switching to the deterministic PRNG aims to nudge future users that need a cryptographically secure RNG away from calling ``random.seed()`` and those that genuinely need a deterministic -generator towards explicitily calling ``random.ensure_repeatable()``. +generator towards explicitly calling ``random.ensure_repeatable()``. Avoiding the introduction of a userspace CSPRNG ----------------------------------------------- diff --git a/pep-0505.rst b/pep-0505.rst index 798e333bb..96bd4ab0c 100644 --- a/pep-0505.rst +++ b/pep-0505.rst @@ -87,7 +87,7 @@ The coalesce rule ***************** The ``coalesce`` rule provides the ``??`` binary operator. Unlike most binary -operators, the right-hand side is not evaulated until the left-hand side is +operators, the right-hand side is not evaluated until the left-hand side is determined to be ``None``. The ``??`` operator binds more tightly than other binary operators as most diff --git a/pep-0508.txt b/pep-0508.txt index 613abb9af..040d49e9a 100644 --- a/pep-0508.txt +++ b/pep-0508.txt @@ -124,7 +124,7 @@ environments:: Optional components of a distribution may be specified using the extras field:: - identifer_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit) + identifier_end = letterOrDigit | (('-' | '_' | '.' )* letterOrDigit) identifier = letterOrDigit identifier_end* name = identifier extras_list = identifier (wsp* ',' wsp* identifier)* diff --git a/pep-0509.txt b/pep-0509.txt index a3eca0273..7a464c7a0 100644 --- a/pep-0509.txt +++ b/pep-0509.txt @@ -291,7 +291,7 @@ incremented) according to the C standard. After an integer overflow, a guard can succeed whereas the watched dictionary key was modified. The bug only occurs at a guard check if -there are exaclty ``2 ** 64`` dictionary creations or modifications +there are exactly ``2 ** 64`` dictionary creations or modifications since the previous guard check. If a dictionary is modified every nanosecond, ``2 ** 64`` modifications diff --git a/pep-0517.txt b/pep-0517.txt index 4188b8b88..239290740 100644 --- a/pep-0517.txt +++ b/pep-0517.txt @@ -54,7 +54,7 @@ and source distributions. Provisional Acceptance ======================= -In accordance with the PyPA's specication process, this PEP has been +In accordance with the PyPA's specification process, this PEP has been `provisionally accepted `_ for initial implementation in ``pip`` and other PyPA tools. diff --git a/pep-0518.txt b/pep-0518.txt index 5d7aba79d..9a93f9d94 100644 --- a/pep-0518.txt +++ b/pep-0518.txt @@ -74,7 +74,7 @@ of issues, such as: projects cannot take advantage of newer setuptools features until their users naturally upgrade the version of setuptools to a newer one. -* The items listed in ``setup_requires`` get implicily installed +* The items listed in ``setup_requires`` get implicitly installed whenever you execute the ``setup.py`` but one of the common ways that the ``setup.py`` is executed is via another tool, such as ``pip``, who is already managing dependencies. This means that @@ -197,7 +197,7 @@ The ``[tool]`` table is where any tool related to your Python project, not just build tools, can have users specify configuration data as long as they use a sub-table within ``[tool]``, e.g. the `flit `_ tool would store its -configuration in ``[tool.flit]``. +configuration in ``[tool.flit]``. We need some mechanism to allocate names within the ``tool.*`` namespace, to make sure that different projects don't attempt to use @@ -375,7 +375,7 @@ other configuration data such as project name and version number may end up in the same file someday where arbitrary code execution is not desired. -And finally, the most popular Python implemenation of YAML is +And finally, the most popular Python implementation of YAML is PyYAML [#pyyaml]_ which is a large project of a few thousand lines of code and an optional C extension module. While in and of itself this isn't necessarily an issue, this becomes more of a problem for @@ -489,7 +489,7 @@ meta.toml setup.toml While keeping with traditional thanks to ``setup.py``, it does not necessarily match what the file may contain in the future (.e.g is - knowing the name of a project inerhently part of its setup?). + knowing the name of a project inherently part of its setup?). pymeta.toml Not obvious to newcomers to programming and/or Python. diff --git a/pep-0519.txt b/pep-0519.txt index ec70c0c28..0e6f160c2 100644 --- a/pep-0519.txt +++ b/pep-0519.txt @@ -460,7 +460,7 @@ the protocol helpfully avoids any accidental opting into the protocol. Provide specific type hinting support ------------------------------------- -There was some consideration to provdinga generic ``typing.PathLike`` +There was some consideration to provding a generic ``typing.PathLike`` class which would allow for e.g. ``typing.PathLike[str]`` to specify a type hint for a path object which returned a string representation. While potentially beneficial, the usefulness was deemed too small to diff --git a/pep-0520.txt b/pep-0520.txt index 7f0908a3c..f8e3366ef 100644 --- a/pep-0520.txt +++ b/pep-0520.txt @@ -171,7 +171,7 @@ which is exactly correct for ``__definition_order__``. Since it represents the state of a particular one-time event (execution of the class definition body), allowing the value to be replaced would reduce confidence that the attribute corresponds to the original class -body. Furthermore, often an immuntable-by-default approach helps to +body. Furthermore, often an immutable-by-default approach helps to make data easier to reason about. However, in this case there still isn't a *strong* reason to counter diff --git a/pep-0521.txt b/pep-0521.txt index d2e3f2ff2..fc6715702 100644 --- a/pep-0521.txt +++ b/pep-0521.txt @@ -41,7 +41,7 @@ example, this code:: yield x may or may not successfully catch warnings raised by ``g()``, and may -or may not inadverdantly swallow warnings triggered elsewhere in the +or may not inadvertently swallow warnings triggered elsewhere in the code. The context manager, which was intended to apply only to ``f`` and its callees, ends up having a dynamic scope that encompasses arbitrary and unpredictable parts of its call\ **ers**. This problem diff --git a/pep-0524.txt b/pep-0524.txt index ccebe7e6b..eaac1e02b 100644 --- a/pep-0524.txt +++ b/pep-0524.txt @@ -222,7 +222,7 @@ On Python 3.5.2, os.urandom() uses the non-blocking ``/dev/urandom`` if ``getrandom(size, GRND_NONBLOCK)`` fails with ``EAGAIN``. -Security experts promotes ``os.urandom()`` to genereate cryptographic +Security experts promotes ``os.urandom()`` to generate cryptographic keys because it is implemented with a `Cryptographically secure pseudo-random number generator (CSPRNG) `_. @@ -435,7 +435,7 @@ not acceptable. The application must handle ``BlockingIOError``: poll except BlockingIOError: pass - print("Wait for system urandom initialiation: move your " + print("Wait for system urandom initialization: move your " "mouse, use your keyboard, use your disk, ...") while 1: # Avoid busy-loop: sleep 1 ms @@ -497,7 +497,7 @@ have a well defined non-blocking API (``getrandom(size, GRND_NONBLOCK)``). As `Raise BlockingIOError in os.urandom()`_, it doesn't seem worth it to -make the API more complex for a theorical (or at least very rare) use +make the API more complex for a theoretical (or at least very rare) use case. As `Leave os.urandom() unchanged, add os.getrandom()`_, the problem is @@ -551,7 +551,7 @@ Since ``os.urandom()`` is implemented in the kernel, it doesn't have issues of user-space RNG. For example, it is much harder to get its state. It is usually built on a CSPRNG, so even if its state is "stolen", it is hard to compute previously generated numbers. The kernel -has a good knowledge of entropy sources and feed regulary the entropy +has a good knowledge of entropy sources and feed regularly the entropy pool. That's also why ``os.urandom()`` is preferred over ``ssl.RAND_bytes()``. diff --git a/pep-0532.txt b/pep-0532.txt index fffcebb16..fa92016d3 100644 --- a/pep-0532.txt +++ b/pep-0532.txt @@ -753,7 +753,7 @@ The same logic applies to ``else``, only reversed:: >>> is_not_none(data.get("key")) else y This expression returns ``data.get("key")`` if it is not ``None``, otherwise it -evaluates and returns ``y``. To understand the mechancics, we rewrite the +evaluates and returns ``y``. To understand the mechanics, we rewrite the expression as follows:: >>> maybe_value = is_not_none(data.get("key")) diff --git a/pep-0533.txt b/pep-0533.txt index e9dcf01e2..d6a8b9909 100644 --- a/pep-0533.txt +++ b/pep-0533.txt @@ -486,7 +486,7 @@ comprehensions): - ``__del__`` calls ``self.close()`` (same as now), and additionally issues a ``ResourceWarning`` if the generator wasn't exhausted. This warning is hidden by default, but can be enabled for those who want - to make sure they aren't inadverdantly relying on CPython-specific + to make sure they aren't inadvertently relying on CPython-specific GC semantics. Async generator objects (including those created by async generator diff --git a/pep-0538.txt b/pep-0538.txt index f15961d2c..1fca7afc3 100644 --- a/pep-0538.txt +++ b/pep-0538.txt @@ -901,7 +901,7 @@ current process and any subprocesses that inherit the current environment. Avoiding setting LANG for UTF-8 locale coercion ----------------------------------------------- -Earlier versions of this PEP proposed setting the ``LANG`` category indepdent +Earlier versions of this PEP proposed setting the ``LANG`` category independent default locale, in addition to setting ``LC_CTYPE``. This was later removed on the grounds that setting only ``LC_CTYPE`` is diff --git a/pep-0539.txt b/pep-0539.txt index c6a10a5f3..ad0b821e6 100644 --- a/pep-0539.txt +++ b/pep-0539.txt @@ -94,7 +94,7 @@ The new TSS API does not provide functions which correspond to ``PyThread_delete_key_value`` and ``PyThread_ReInitTLS``, because these functions were needed only for CPython's now defunct built-in TLS implementation; that is the existing behavior of these functions is treated -as follows: ``PyThread_delete_key_value(key)`` is equalivalent to +as follows: ``PyThread_delete_key_value(key)`` is equivalent to ``PyThread_set_key_value(key, NULL)``, and ``PyThread_ReInitTLS()`` is a no-op [8]_. diff --git a/pep-0543.rst b/pep-0543.rst index 539863ac7..05a813e3d 100644 --- a/pep-0543.rst +++ b/pep-0543.rst @@ -157,7 +157,7 @@ are: presented by a remote peer. 11. Finding a way to get hold of these interfaces at run time. -For the sake of simplicitly, this PEP proposes to take a unified approach to +For the sake of simplicity, this PEP proposes to take a unified approach to (2) and (3) (that is, buffers and sockets). The Python socket API is a sizeable one, and implementing a wrapped socket that has the same behaviour as a regular Python socket is a subtle and tricky thing to do. However, it is diff --git a/pep-0545.txt b/pep-0545.txt index a30373670..f5a1a53f9 100644 --- a/pep-0545.txt +++ b/pep-0545.txt @@ -492,7 +492,7 @@ Create Github Repository ------------------------ Create a repository named "python-docs-{LANGUAGE_TAG}" (IETF language -tag, without redundent region subtag, with a dash, and lowercased.) on +tag, without redundant region subtag, with a dash, and lowercased.) on the Python GitHub organization (See `Repository For Po Files`_.), and grant the language coordinator push rights to this repository. diff --git a/pep-0554.rst b/pep-0554.rst index aedd668bb..1e7217f96 100644 --- a/pep-0554.rst +++ b/pep-0554.rst @@ -457,7 +457,7 @@ to the language (or stdlib) has a cost in increasing the size of the language. So an addition must pay for itself. In this case, subinterpreters provide a novel concurrency model focused on isolated threads of execution. Furthermore, they provide an opportunity for -changes in CPython that will allow simulateous use of multiple CPU +changes in CPython that will allow simultaneous use of multiple CPU cores (currently prevented by the GIL). Alternatives to subinterpreters include threading, async, and @@ -1384,7 +1384,7 @@ executes. The idea is rejected because the benefit is small and the cost is high. The difference from the capability in the C-API would be potentially -confusing. The implcit creation of threads is magical. The early +confusing. The implicit creation of threads is magical. The early creation of threads is potentially wasteful. The inability to run arbitrary interpreters in an existing thread would prevent some valid use cases, frustrating users. Tying interpreters to threads would diff --git a/pep-0557.rst b/pep-0557.rst index 915aae6f4..fc5348ef2 100644 --- a/pep-0557.rst +++ b/pep-0557.rst @@ -778,7 +778,7 @@ For example:: Because the ``__post_init__`` function is the last thing called in the generated ``__init__``, having a classmethod constructor (which can -also execute code immmediately after constructing the object) is +also execute code immediately after constructing the object) is functionally equivalent to being able to pass parameters to a ``__post_init__`` function. diff --git a/pep-0563.rst b/pep-0563.rst index 561bb4bcf..6d2d275fd 100644 --- a/pep-0563.rst +++ b/pep-0563.rst @@ -455,7 +455,7 @@ Instead of requiring the following import:: the PEP could call the feature more explicitly, for example ``string_annotations``, ``stringify_annotations``, -``annotation_strings``, ``annotations_as_strings``, ``lazy_anotations``, +``annotation_strings``, ``annotations_as_strings``, ``lazy_annotations``, ``static_annotations``, etc. The problem with those names is that they are very verbose. Each of @@ -666,7 +666,7 @@ This document could not be completed without valuable input, encouragement and advice from Guido van Rossum, Jukka Lehtosalo, and Ivan Levkivskyi. -The implementation was throroughly reviewed by Serhiy Storchaka who +The implementation was thoroughly reviewed by Serhiy Storchaka who found all sorts of issues, including bugs, bad readability, and performance problems. diff --git a/pep-0571.rst b/pep-0571.rst index fd0697b51..7072765b1 100644 --- a/pep-0571.rst +++ b/pep-0571.rst @@ -222,7 +222,7 @@ material for ROP gadgets, mapped into the process. [14]_ ``vsyscall=emulated`` has been the default configuration in most distribution's kernels for many years. -Unfortunately, ``vsyscall`` emulation still exposes predicatable code +Unfortunately, ``vsyscall`` emulation still exposes predictable code at a reliable memory location, and continues to be useful for return-oriented programming. [15]_ Because most distributions have now upgraded to ``glibc`` versions that do not depend on ``vsyscall``, diff --git a/pep-0573.rst b/pep-0573.rst index 5004fcf9e..466895166 100644 --- a/pep-0573.rst +++ b/pep-0573.rst @@ -437,7 +437,7 @@ easier, a helper will be added:: This function takes a heap type and on success, it returns pointer to state of the module that the heap type belongs to. -On failure, two scenarios may occure. When a type without a module is passed in, +On failure, two scenarios may occur. When a type without a module is passed in, ``SystemError`` is set and ``NULL`` returned. If the module is found, pointer to the state, which may be ``NULL``, is returned without setting any exception. diff --git a/pep-0574.rst b/pep-0574.rst index 8a283b19f..d665e5f0c 100644 --- a/pep-0574.rst +++ b/pep-0574.rst @@ -352,7 +352,7 @@ such as Numpy arrays, need to be backed by a mutable buffer for full operation. Pickle consumers that use the ``buffer_callback`` and ``buffers`` arguments will have to be careful to recreate mutable buffers. When doing I/O, this implies using buffer-passing API variants such as ``readinto`` -(which are also often preferrable for performance). +(which are also often preferable for performance). Data sharing ------------ diff --git a/pep-0575.rst b/pep-0575.rst index 73f9b2e7c..92d6e061f 100644 --- a/pep-0575.rst +++ b/pep-0575.rst @@ -823,7 +823,7 @@ In the Python standard library for example, changes are needed in the ``doctest`` module because of this. Also, tools which take various kinds of functions as input will need to deal -with the new function hieararchy and the possibility of custom +with the new function hierarchy and the possibility of custom function classes. Python functions diff --git a/pep-0576.rst b/pep-0576.rst index 84251763c..bd0f4c95f 100644 --- a/pep-0576.rst +++ b/pep-0576.rst @@ -52,7 +52,7 @@ Currently the majority of calls are dispatched to ``function``\s and ``method_de Continued prohibition of callable classes as base classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Currently any attempt to use ``function``, ``method`` or ``method_descriptor`` as a base class for a new class will fail with a ``TypeError``. This behaviour is desirable as it prevents errors when a subclass overrides the ``__call__`` method. If callables could be sub-classed then any call to a ``function`` or a ``method_descriptor`` would need an additional check that the ``__call__`` method had not been overridden. By exposing an additional call mechanism, the potential for errors becomes greater. As a consequence, any third-partyy class implementing the addition call interface will not be usable as a base class. +Currently any attempt to use ``function``, ``method`` or ``method_descriptor`` as a base class for a new class will fail with a ``TypeError``. This behaviour is desirable as it prevents errors when a subclass overrides the ``__call__`` method. If callables could be sub-classed then any call to a ``function`` or a ``method_descriptor`` would need an additional check that the ``__call__`` method had not been overridden. By exposing an additional call mechanism, the potential for errors becomes greater. As a consequence, any third-party class implementing the addition call interface will not be usable as a base class. New classes and changes to existing classes diff --git a/pep-0577.rst b/pep-0577.rst index 278a20d5c..b605c76f7 100644 --- a/pep-0577.rst +++ b/pep-0577.rst @@ -28,7 +28,7 @@ technically allows inline augmented assignments to be written using the ... The restriction to simple names as inline assignment targets means that the -target expession can always be repeated without side effects, and thus avoids +target expression can always be repeated without side effects, and thus avoids the ambiguity that would arise from allowing actual embedded augmented assignments (it's still a bad idea, since it would almost certainly be hard for humans to read, this note is just about the theoretical limits of language diff --git a/pep-0582.rst b/pep-0582.rst index 3d94ac1bb..44a198e13 100644 --- a/pep-0582.rst +++ b/pep-0582.rst @@ -157,7 +157,7 @@ the current directory, instead if there is a ``__pypackages__`` directory in the same path of the script, that will be used. For example, if we execute ``python /usr/share/myproject/fancy.py`` from the -``/tmp`` dirctory and if there is a ``__pypackages__`` directory inside of +``/tmp`` directory and if there is a ``__pypackages__`` directory inside of ``/usr/share/myproject/`` directory, it will be used. Any potential ``__pypackages__`` directory in ``/tmp`` will be ignored. diff --git a/pep-0587.rst b/pep-0587.rst index 6cf569df4..42a2b8a0f 100644 --- a/pep-0587.rst +++ b/pep-0587.rst @@ -331,7 +331,7 @@ The ``legacy_windows_fs_encoding`` field is only available on Windows. * ``_config_version`` (``int``): Configuration version, used for ABI compatibility. * ``_config_init`` (``int``): - Function used to initalize ``PyConfig``, used for preinitialization. + Function used to initialize ``PyConfig``, used for preinitialization. ``PyMem_SetAllocator()`` can be called after ``Py_PreInitialize()`` and before ``Py_InitializeFromConfig()`` to install a custom memory @@ -585,7 +585,7 @@ Options`_. * ``_config_version`` (``int``): Configuration version, used for ABI compatibility. * ``_config_init`` (``int``): - Function used to initalize ``PyConfig``, used for preinitialization. + Function used to initialize ``PyConfig``, used for preinitialization. * ``_install_importlib`` (``int``): Install importlib? * ``_init_main`` (``int``): diff --git a/pep-0590.rst b/pep-0590.rst index 23f8e84a5..9ac3e9d8a 100644 --- a/pep-0590.rst +++ b/pep-0590.rst @@ -111,7 +111,7 @@ The call takes the form ``((vectorcallfunc)(((char *)o)+offset))(o, args, n, kwn ``offset`` is ``Py_TYPE(o)->tp_vectorcall_offset``. The caller is responsible for creating the ``kwnames`` tuple and ensuring that there are no duplicates in it. -``n`` is the number of postional arguments plus possibly the ``PY_VECTORCALL_ARGUMENTS_OFFSET`` flag. +``n`` is the number of positional arguments plus possibly the ``PY_VECTORCALL_ARGUMENTS_OFFSET`` flag. PY_VECTORCALL_ARGUMENTS_OFFSET ------------------------------ diff --git a/pep-0591.rst b/pep-0591.rst index 9db42e931..f0f5fc17a 100644 --- a/pep-0591.rst +++ b/pep-0591.rst @@ -262,7 +262,7 @@ A related feature to final classes would be Scala-style sealed classes, where a class is allowed to be inherited only by classes defined in the same module. Sealed classes seem most useful in combination with pattern matching, so it does not seem to justify the -complexity in our case. This could be revisisted in the future. +complexity in our case. This could be revisited in the future. It would be possible to have the ``@final`` decorator on classes dynamically prevent subclassing at runtime. Nothing else in ``typing`` diff --git a/pep-0592.rst b/pep-0592.rst index ec3dff148..fd0103026 100644 --- a/pep-0592.rst +++ b/pep-0592.rst @@ -94,7 +94,7 @@ the original order to install the now yanked file, then it acts as if it had not been yaned. An installer **MUST** ignore yanked releases, if the selection constraints -can be satisified with a non-yanked version, and **MAY** refuse to use a +can be satisfied with a non-yanked version, and **MAY** refuse to use a yanked release even if it means that the request cannot be satisfied at all. An implementation **SHOULD** choose a policy that follows the spirit of the intention above, and that prevents "new" dependencies on yanked diff --git a/pep-0595.rst b/pep-0595.rst index 3afca726d..5d025a46e 100644 --- a/pep-0595.rst +++ b/pep-0595.rst @@ -45,7 +45,7 @@ on GitHub Issues. workflow evolved. It is possible to gradually improve it and avoid the disruption - that a switch to a different system would inevitabily bring to + that a switch to a different system would inevitably bring to the workflow. * **Open-source and Python powered.** Roundup is an open-source @@ -292,7 +292,7 @@ only when someone wants to keep working on them. This approach has several issues, but there are also other issues that will need to be addressed regardless of the approach used: -* **Vendor lock-in.** GitHub is properietary and there is risk +* **Vendor lock-in.** GitHub is proprietary and there is risk of vendor lock-in. Their business model might change and they could shut down altogether. For example, several projects decided to move away from GitHub after Microsoft acquisition. diff --git a/pep-0597.rst b/pep-0597.rst index cc9061b9f..2ba750fee 100644 --- a/pep-0597.rst +++ b/pep-0597.rst @@ -210,7 +210,7 @@ And there are many difficulty there: * Omitting ``encoding`` option is very common. * If we raise ``DeprecationWarning`` always, it will be too noisy. - * We can not assume how user use it. Complicated heuritics may be + * We can not assume how user use it. Complicated heuristics may be needed to raise ``DeprecationWarning`` only when it is really needed. diff --git a/pep-0598.rst b/pep-0598.rst index 3edc316ad..0078dfc29 100644 --- a/pep-0598.rst +++ b/pep-0598.rst @@ -497,7 +497,7 @@ to the way that PEP 596 proposes to starting publishing Python 3.9.0 alpha releases during the Python 3.8.0 release candidate period). However, rather than setting specific timelines for that at a policy level, -it may make sense to leave that decision to invididual release managers, based +it may make sense to leave that decision to individual release managers, based on the specific changes that are being proposed for the release they're managing. diff --git a/pep-0628.txt b/pep-0628.txt index 5eed09ca1..c59ee8899 100644 --- a/pep-0628.txt +++ b/pep-0628.txt @@ -60,7 +60,7 @@ Other Resources I've barely skimmed the surface of the many examples put forward to point out just how much *easier* and more *sensible* many aspects of mathematics become when conceived in terms of ``tau`` rather than ``pi``. If you don't find my -specific examples sufficiently persausive, here are some more resources that +specific examples sufficiently persuasive, here are some more resources that may be of interest: * Michael Hartl is the primary instigator of Tau Day in his `Tau Manifesto`_ diff --git a/pep-3103.txt b/pep-3103.txt index c18eaab3a..274b507f4 100644 --- a/pep-3103.txt +++ b/pep-3103.txt @@ -189,7 +189,7 @@ to match on a single expression; use:: case EXPR, EXPR, ...: -to match on mulltiple expressions. The is interpreted so that if EXPR +to match on multiple expressions. The is interpreted so that if EXPR is a parenthesized tuple or another expression whose value is a tuple, the switch expression must equal that tuple, not one of its elements. This means that we cannot use a variable to indicate multiple cases. @@ -432,7 +432,7 @@ that overkill.) Personally, I'm in school II: I believe that the dict-based dispatch is the one true implementation for switch statements and that we -should face the limitiations up front, so that we can reap maximal +should face the limitations up front, so that we can reap maximal benefits. I'm leaning towards school IIb -- duplicate cases should be resolved by the ordering of the cases instead of flagged as errors. diff --git a/pep-3108.txt b/pep-3108.txt index 446dc5fe0..63bb485df 100644 --- a/pep-3108.txt +++ b/pep-3108.txt @@ -206,7 +206,7 @@ reasonable because of this fact. - Wrapper for SGI libimage library for imglib image files (``.rgb`` files). - - Python Imaging Library provdes read-only support [#pil]_. + - Python Imaging Library provides read-only support [#pil]_. - Not uniquely edited in 13 years. + IN diff --git a/pep-3118.txt b/pep-3118.txt index ca0ae3812..74b56c4d0 100644 --- a/pep-3118.txt +++ b/pep-3118.txt @@ -362,7 +362,7 @@ The members of the bufferinfo structure are: set to NULL or an PyExc_BufferError raised if this is not possible. For clarity, here is a function that returns a pointer to the - element in an N-D array pointed to by an N-dimesional index when + element in an N-D array pointed to by an N-dimensional index when there are both non-NULL strides and suboffsets:: void *get_item_pointer(int ndim, void *buf, Py_ssize_t *strides, diff --git a/pep-3137.txt b/pep-3137.txt index a1f0bde5f..7e94b5fa5 100644 --- a/pep-3137.txt +++ b/pep-3137.txt @@ -125,7 +125,7 @@ bytearray: [, ])``: encode a text string. Note that the ``str.encode()`` method returns an *immutable* bytes object. The argument is mandatory; is optional. - and , if given, must be ``str`` instances. + and , if given, must be ``str`` instances. - ``bytes()``, ``bytearray()``: construct a bytes or bytearray object from anything that implements the PEP diff --git a/pep-3138.txt b/pep-3138.txt index 6553318dc..b5018fc7a 100644 --- a/pep-3138.txt +++ b/pep-3138.txt @@ -55,7 +55,7 @@ We can use ``print(aJapaneseString)`` to get a readable string, but we don't have a similar workaround for printing strings from collections such as lists or tuples. ``print(listOfJapaneseStrings)`` uses repr() to build the string to be printed, so the resulting strings are always -hex-escaped. Or when ``open(japaneseFilemame)`` raises an exception, +hex-escaped. Or when ``open(japaneseFilename)`` raises an exception, the error message is something like ``IOError: [Errno 2] No such file or directory: '\u65e5\u672c\u8a9e'``, which isn't helpful. diff --git a/pep-3150.txt b/pep-3150.txt index 8856c122a..d7fd9525a 100644 --- a/pep-3150.txt +++ b/pep-3150.txt @@ -717,7 +717,7 @@ Rejected Alternatives the general structure of the syntax as defined in this PEP (For example, allowing a subexpression like ``?given`` or ``:given`` to be used in expressions to indicate a direct reference to the implied closure, thus - preventig it from being called automatically to create the local namespace). + preventing it from being called automatically to create the local namespace). All such attempts have appeared unattractive and confusing compared to the simpler decorator-inspired proposal in PEP 403. diff --git a/pep-3151.txt b/pep-3151.txt index 8f09a07a0..1b4a8bb4c 100644 --- a/pep-3151.txt +++ b/pep-3151.txt @@ -437,7 +437,7 @@ Naming Various naming controversies can arise. One of them is whether all exception class names should end in "``Error``". In favour is consistency -with the rest of the exception hiearchy, against is concision (especially +with the rest of the exception hierarchy, against is concision (especially with long names such as ``ConnectionAbortedError``). Exception attributes diff --git a/pep-3333.txt b/pep-3333.txt index c67049cd0..09145bb78 100644 --- a/pep-3333.txt +++ b/pep-3333.txt @@ -983,7 +983,7 @@ portion of the response that precedes it. In these cases, applications will usually return an iterator (often a generator-iterator) that produces the output in a block-by-block -fashion. These blocks may be broken to coincide with mulitpart +fashion. These blocks may be broken to coincide with multipart boundaries (for "server push"), or just before time-consuming tasks (such as reading another block of an on-disk file). diff --git a/pep-8001.rst b/pep-8001.rst index af9cdf26b..886fc9cc3 100644 --- a/pep-8001.rst +++ b/pep-8001.rst @@ -283,7 +283,7 @@ cryptographic systems for Condorcet ballots, the CIVS system was chosen to act as a trusted party. More information about the security and privacy afforded by CIVS, including -how a malicous voter, election supervisor, or CIVS administrator can +how a malicious voter, election supervisor, or CIVS administrator can influence the election can be be found `here `_. diff --git a/pep-8002.rst b/pep-8002.rst index f591f7fc6..a9c5493cc 100644 --- a/pep-8002.rst +++ b/pep-8002.rst @@ -64,7 +64,7 @@ Key people and their functions In the Rust project there are teams responsible for certain areas. For language features there is a "lang team", for tooling there's "dev tools" and "Cargo", and so on. Contentious issues have facilitators to drive discussion who often aren't the decision -makers. Typically the faciliators are authors of the proposed changes (see +makers. Typically the facilitators are authors of the proposed changes (see "Controversial decision process" below). They ensure all key decision makers are involved along with interested community members. They push towards an agreeable outcome via iteration. @@ -622,7 +622,7 @@ Controversial decision process ------------------------------ Hejlsberg is the central figure of the project in terms of language -design, sythesizing community needs into a cohesive whole. There is +design, synthesizing community needs into a cohesive whole. There is no formal process to externally contribute to the design of the language. @@ -941,7 +941,7 @@ Jeremy Stanley, Chris Dent, Julia Kreger, Sean McGinnis, Emmet Hikory, and Thierry Carrez contributed to the OpenStack section. The Project Jupyter Steering Council created the Main Governance Document for -Project Jupyter, and Carol Willing summarized the key points of that documennt +Project Jupyter, and Carol Willing summarized the key points of that document for the Jupyter section. Thank you to Carl Meyer from the Django team for explanation how their diff --git a/pep-8012.rst b/pep-8012.rst index d9f992165..18cbcc67a 100644 --- a/pep-8012.rst +++ b/pep-8012.rst @@ -187,7 +187,7 @@ Rationale ========= **Inclusive** The Community Model is the most inclusive model. No single person -or a small group of people is in a distiguished position of power over +or a small group of people is in a distinguished position of power over others. Contributors and any workgroups in this model are self-selecting. **Pragmatic** This model ensures no user group is put at a disadvantage due to diff --git a/pep-8014.rst b/pep-8014.rst index 8ce70745e..73e5bf7f6 100644 --- a/pep-8014.rst +++ b/pep-8014.rst @@ -278,9 +278,9 @@ member can be retired by a unanimous vote by the rest of the council. There is an emergency brake procedure to get rid of a non-functioning council. A single Elder or a group of 10 core developers or PSF voting members can ask for -an immedeate reinstating vote of the council as a whole (presumably with the +an immediate reinstating vote of the council as a whole (presumably with the intention that the council lose their mandate). If this vote has been requested by an -Elder that individual immedeately lose their council position, independent of +Elder that individual immediately lose their council position, independent of the outcome of the vote. If the vote has been requested by community members and the council is reinstated this procedure cannot be invoked again for a year. @@ -304,7 +304,7 @@ to be handled by the Council of Elders. This falls to the community as a whole There is also the role of figurehead or spokesperson to represent Python and the Python community to the outside world. Again, this is *not* a role that -should be handled by the Council of Elders, in my opionion, but by some +should be handled by the Council of Elders, in my opinion, but by some other person or body. Note that this proposal most likely favors conservatism over progression. Or, at least, the