diff --git a/pep-0001.txt b/pep-0001.txt index e50c5e474..28aa0c650 100644 --- a/pep-0001.txt +++ b/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. diff --git a/pep-0520.txt b/pep-0520.txt index f8e3366ef..56a48b45b 100644 --- a/pep-0520.txt +++ b/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. diff --git a/pep-0545.txt b/pep-0545.txt index 1178b5b86..7e0bcdaa6 100644 --- a/pep-0545.txt +++ b/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. diff --git a/pep-0554.rst b/pep-0554.rst index f50f0032d..330cba3f4 100644 --- a/pep-0554.rst +++ b/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. diff --git a/pep-0555.rst b/pep-0555.rst index 929f99570..f001601aa 100644 --- a/pep-0555.rst +++ b/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 ============== diff --git a/pep-0589.rst b/pep-0589.rst index c296e6af6..dd7550e31 100644 --- a/pep-0589.rst +++ b/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. diff --git a/pep-0590.rst b/pep-0590.rst index 9ac3e9d8a..fabd4df7b 100644 --- a/pep-0590.rst +++ b/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 diff --git a/pep-0591.rst b/pep-0591.rst index 8c1997ed2..6b6bacffc 100644 --- a/pep-0591.rst +++ b/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[]``. Example:: diff --git a/pep-0592.rst b/pep-0592.rst index 6172b8dd4..5fa497e6e 100644 --- a/pep-0592.rst +++ b/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. diff --git a/pep-0593.rst b/pep-0593.rst index 90c3bfccf..a91b66b44 100644 --- a/pep-0593.rst +++ b/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 ------------- diff --git a/pep-0605.rst b/pep-0605.rst index f0cb78f83..76020b347 100644 --- a/pep-0605.rst +++ b/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 diff --git a/pep-0611.rst b/pep-0611.rst index 52943f0f2..510f71b89 100644 --- a/pep-0611.rst +++ b/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. diff --git a/pep-0615.rst b/pep-0615.rst index bbf13299e..c7e617399 100644 --- a/pep-0615.rst +++ b/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. diff --git a/pep-0621.rst b/pep-0621.rst index 6b8dd478f..338ac821a 100644 --- a/pep-0621.rst +++ b/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. diff --git a/pep-0622.rst b/pep-0622.rst index ec0c09c2f..b9b95a65a 100644 --- a/pep-0622.rst +++ b/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. diff --git a/pep-0626.rst b/pep-0626.rst index b2ea6a51f..82bd14f19 100644 --- a/pep-0626.rst +++ b/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: diff --git a/pep-0636.rst b/pep-0636.rst index cb9e804fa..72ec6964a 100644 --- a/pep-0636.rst +++ b/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. diff --git a/pep-0638.rst b/pep-0638.rst index 8d2b89351..2e1884248 100644 --- a/pep-0638.rst +++ b/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`` diff --git a/pep-8001.rst b/pep-8001.rst index 91a89c75b..ca0228fc7 100644 --- a/pep-8001.rst +++ b/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 `_. Why cannot voters change their vote? diff --git a/pep-8002.rst b/pep-8002.rst index a9c5493cc..70a5e61b8 100644 --- a/pep-8002.rst +++ b/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 diff --git a/pep-8011.rst b/pep-8011.rst index fee232571..1caa403c1 100644 --- a/pep-8011.rst +++ b/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. diff --git a/pep-8015.rst b/pep-8015.rst index 4b5359216..630792ad0 100644 --- a/pep-8015.rst +++ b/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.