Typos: Remove repeated words (#1726)

pep-0001.txt

@@ -486,8 +486,8 @@ Each PEP should have the following parts/sections:
     warrant further discussion. Those ideas should be recorded so people
     know that they are being thought about but do not have a concrete
     resolution. This helps make sure all issues required for the PEP to be
-    ready for consideration are complete complete and reduces people
-    duplicating prior discussion.
+    ready for consideration are complete and reduces people duplicating
+    prior discussion.
 
 12. References -- A collection of URLs used as references through the PEP.
 

pep-0520.txt

@@ -258,7 +258,7 @@ so that consumers of ``__definition_order__`` may have a consistent
 expectation for the value.  That helps maximize the feature's
 usefulness.
 
-We could also also allow an arbitrary iterable for a manually set
+We could also allow an arbitrary iterable for a manually set
 ``__definition_order__`` and convert it into a tuple.  However, not
 all iterables infer a definition order (e.g. ``set``).  So we opt in
 favor of requiring a tuple.

pep-0545.txt

@@ -207,12 +207,12 @@ states that tags are not case sensitive.  As the RFC allows lower case,
 and it enhances readability, we should use lowercased tags like
 ``pt-br``.
 
-We may drop the region subtag when it does does not add
-distinguishing information, for example: "de-DE" or "fr-FR".
-(Although it might make sense, respectively meaning "German as
-spoken in Germany" and "French as spoken in France"). But when
-the region subtag actually adds information, for example "pt-BR"
-for "Portuguese as spoken in Brazil", it should be kept.
+We may drop the region subtag when it does not add distinguishing
+information, for example: "de-DE" or "fr-FR". (Although it might
+make sense, respectively meaning "German as spoken in Germany"
+and "French as spoken in France"). But when the region subtag
+actually adds information, for example "pt-BR" or "Portuguese as
+spoken in Brazil", it should be kept.
 
 So we should use IETF language tags, lowercased, like ``/fr/``,
 ``/pt-br/``, ``/de/`` and so on.

pep-0554.rst

@@ -515,7 +515,7 @@ which subinterpreters are worth it.
   experimentation, so the new module shouldn't go into the stdlib
   right away, if ever"
 
-Introducing an API for a a new concurrency model, like happened with
+Introducing an API for a new concurrency model, like happened with
 asyncio, is an extremely large project that requires a lot of careful
 consideration.  It is not something that can be done a simply as this
 PEP proposes and likely deserves significant time on PyPI to mature.

pep-0555.rst

@@ -377,7 +377,7 @@ Open Issues
 Out-of-order de-assignments
 ---------------------------
 
-In this proposal, all variable deassignments are made in the opposite order compared to the preceding assignments. This has two useful properties: it encourages using ``with`` statements to define assignment scope and has a tendency to catch errors early (forgetting a ``.__exit__()`` call often results in a meaningful error. To have this as a requirement requirement is beneficial also in terms of implementation simplicity and performance. Nevertheless, allowing out-of-order context exits is not completely out of the question, and reasonable implementation strategies for that do exist.
+In this proposal, all variable deassignments are made in the opposite order compared to the preceding assignments. This has two useful properties: it encourages using ``with`` statements to define assignment scope and has a tendency to catch errors early (forgetting a ``.__exit__()`` call often results in a meaningful error. To have this as a requirement is beneficial also in terms of implementation simplicity and performance. Nevertheless, allowing out-of-order context exits is not completely out of the question, and reasonable implementation strategies for that do exist.
 
 Rejected Ideas
 ==============

pep-0589.rst

@@ -58,7 +58,7 @@ to be type checked more effectively.
 
 More generally, representing pure data objects using only Python
 primitive types such as dictionaries, strings and lists has had
-certain appeal.  They are are easy to serialize and deserialize even
+certain appeal.  They are easy to serialize and deserialize even
 when not using JSON.  They trivially support various useful operations
 with no extra effort, including pretty-printing (through ``str()`` and
 the ``pprint`` module), iteration, and equality comparisons.
@@ -616,7 +616,7 @@ Rejected Alternatives
 =====================
 
 Several proposed ideas were rejected.  The current set of features
-seem to cover a lot of ground, and it was not not clear which of the
+seem to cover a lot of ground, and it was not clear which of the
 proposed extensions would be more than marginally useful.  This PEP
 defines a baseline feature that can be potentially extended later.
 

pep-0590.rst

@@ -82,7 +82,7 @@ If ``_Py_TPFLAGS_HAVE_VECTORCALL`` is set, then ``tp_vectorcall_offset`` must be
 It is the offset into the object of the vectorcall function pointer of type ``vectorcallfunc``.
 This pointer may be ``NULL``, in which case the behavior is the same as if ``_Py_TPFLAGS_HAVE_VECTORCALL`` was not set.
 
-The ``tp_print`` slot is reused as the ``tp_vectorcall_offset`` slot to make it easier for for external projects to backport the vectorcall protocol to earlier Python versions.
+The ``tp_print`` slot is reused as the ``tp_vectorcall_offset`` slot to make it easier for external projects to backport the vectorcall protocol to earlier Python versions.
 In particular, the Cython project has shown interest in doing that (see https://mail.python.org/pipermail/python-dev/2018-June/153927.html).
 
 Descriptor behavior

pep-0591.rst

@@ -129,7 +129,7 @@ variable or attribute should not be reassigned, redefined, or overridden.
 Syntax
 ~~~~~~
 
-``Final`` may be used in in one of several forms:
+``Final`` may be used in one of several forms:
 
 * With an explicit type, using the syntax ``Final[<type>]``. Example::
 

pep-0592.rst

@@ -174,7 +174,7 @@ yanking or unyanking an entire release, rather than as an operation on
 individual files, which will then be exposed via the API as individual
 files being yanked.
 
-Other repository implementations may choose to to expose this capability
+Other repository implementations may choose to expose this capability
 in a different way, or not expose it at all.
 
 

pep-0593.rst

@@ -107,9 +107,8 @@ proof-of-concept and have people with type checkers (or other tools) that don't
 yet support this feature work in a codebase with tagged unions. The author could
 easily test this proposal and iron out the kinks before trying to upstream tagged
 union to ``typing``, mypy, etc. Moreover, tools that do not have support for
-parsing the ``TaggedUnion`` annotation would still be able able to treat
-``Currency`` as a ``TypedDict``, which is still a close approximation (slightly
-less strict).
+parsing the ``TaggedUnion`` annotation would still be able to treat ``Currency``
+as a ``TypedDict``, which is still a close approximation (slightly less strict).
 
 Specification
 -------------

pep-0605.rst

@@ -674,8 +674,8 @@ pre-freeze release may not load correctly on an earlier pre-freeze release.
 
 The documentation for alpha releases and the stable C ABI would make it clear
 that even extension modules built against the stable ABI in an alpha release
-release may not load correctly on the next release if two alpha releases are
-published in a row (this situation would ideally be rare).
+may not load correctly on the next release if two alpha releases are published
+in a row (this situation would ideally be rare).
 
 
 Changes to management of the full CPython ABI

pep-0611.rst

@@ -38,7 +38,7 @@ It is unsafe as malicious or poorly generated code could cause values to exceed
 
 For example, line numbers are represented by 32 bit values internally. 
 This is inefficient, given that modules almost never exceed a few thousand lines.
-Despite being inefficient, is is still vulnerable to overflow as
+Despite being inefficient, is still vulnerable to overflow as
 it is easy for an attacker to created a module with billions of newline characters.
 
 Memory access is usually a limiting factor in the performance of modern CPUs.

pep-0615.rst

@@ -857,7 +857,7 @@ Footnotes
 
 .. [d]
     The term "first party" here is distinguished from "third party" in that,
-    although it is is distributed via PyPI and is not currently included in
+    although it is distributed via PyPI and is not currently included in
     Python by default, it is to be considered an official sub-project of
     CPython rather than a "blessed" third-party package.
 

pep-0621.rst

@@ -653,7 +653,7 @@ standardize on ``Author`` in the core metadata as the place to list
 people maintaining a project.
 
 In the end, though, the decision to adhere to the core metadata was
-deemed more important to help with the the acceptance of this PEP,
+deemed more important to help with the acceptance of this PEP,
 rather than trying to introduce a new interpretation for some of the
 core metadata.
 

pep-0622.rst

@@ -2167,7 +2167,7 @@ Pattern Utility Library
 
 Both of the previous ideas would be accompanied by a new Python standard
 library module which would contain a rich set of useful matchers.
-However, it it not really possible to implement such a library without
+However, it is not really possible to implement such a library without
 adopting one of the extended pattern proposals given in the previous sections,
 so this idea is also deferred.
 

pep-0626.rst

@@ -161,7 +161,7 @@ each representing the line number of a range of bytecodes. Each tuple will consi
 
 * ``start`` -- The offset (inclusive) of the start of the bytecode range
 * ``end`` -- The offset (exclusive) of the end of the bytecode range
-* ``line`` -- The line number, or ``None`` if the the bytecodes in the given range do not have a line number.
+* ``line`` -- The line number, or ``None`` if the bytecodes in the given range do not have a line number.
 
 The sequence generated will have the following properties:
 

pep-0636.rst

@@ -316,7 +316,7 @@ different kinds of objects, and also apply patterns to its attributes::
         case other_event:
             raise ValueError(f"Unrecognized event: {other_event}")
 
-A pattern like ``Click(position=(x, y))`` only matches if the the type of the event is
+A pattern like ``Click(position=(x, y))`` only matches if the type of the event is
 a subclass of the ``Click`` class. It will also requires that the event has a ``position``
 attribute that matches the ``(x, y)`` pattern. If there's a match, the locals ``x`` and
 ``y`` will get the expected values.

pep-0638.rst

@@ -92,7 +92,7 @@ Long term stability for the bytecode interpreter
 Historically, new language features have been implemented by naive compilation
 of the AST into new, complex bytecode instructions.
 Those bytecodes have often had their own internal flow-control, performing
-operations that that could, and should, have been done in the compiler.
+operations that could, and should, have been done in the compiler.
 
 For example,
 until recently flow control within the ``try``-``finally`` and ``with``

pep-8001.rst

@@ -284,7 +284,7 @@ act as a trusted party.
 
 More information about the security and privacy afforded by CIVS, including
 how a malicious voter, election supervisor, or CIVS administrator can
-influence the election can be be found
+influence the election can be found
 `here <https://civs.cs.cornell.edu/sec_priv.html>`_.
 
 Why cannot voters change their vote?

pep-8002.rst

@@ -258,7 +258,7 @@ WeChat, instead.
 The tool used for discussing any given decision will vary based on its
 weight and impact. Everyone is encouraged to use either the mailing
 list or gerrit to support asynchronous discussion across a wider range
-of timezones and and firewalls, especially for publicizing final
+of timezones and firewalls, especially for publicizing final
 decisions for the rest of the community.
 
 Policy decisions limited to a single team are usually made by the core

pep-8011.rst

@@ -158,7 +158,7 @@ Diversity and inclusivity
 
 The core Python development team fully supports the Python Software Foundation’s
 diversity statement, and welcomes participation and contribution from people
-from diverse backgrounds. When nominating people to to be part of the trio,
+from diverse backgrounds. When nominating people to be part of the trio,
 Python core developers will take every effort into including members from
 underrepresented group into consideration.
 

pep-8015.rst

@@ -224,7 +224,7 @@ options:
   a core developer who will take the final decision for the specific
   PEP. The committee select the PEP delegate who can be proposed by the
   Python team where the PEP is discussed.
-* The committee can organize a vote on on the PEP, see `PEP process`_
+* The committee can organize a vote on the PEP, see `PEP process`_
   for the vote organization. The committee decides when the vote is
   organized. A vote is preferred for changes affecting all Python users,
   like language changes.