Copyedits to PEP 679 (#2222)

Co-authored-by: Hugo van Kemenade <[email protected]>

.github/CODEOWNERS

@@ -534,6 +534,7 @@ pep-0675.rst  @jellezijlstra
 pep-0676.rst  @Mariatta
 pep-0677.rst  @gvanrossum
 pep-0678.rst  @iritkatriel
+pep-0679.rst  @pablogsal
 # ...
 # pep-0754.txt
 # ...

pep-0679.rst

@@ -12,7 +12,7 @@ Python-Version: 3.11
 Abstract
 ========
 
-This pep proposes to allow parentheses surrounding the two-subject form of
+This PEP proposes to allow parentheses surrounding the two-argument form of
 assert statements. This will cause the interpreter to reinterpret what before
 would have been an assert with a two-element tuple that will always be True
 (``assert (expression, message)``) to an assert statement with a subject and a
@@ -23,22 +23,21 @@ failure message, equivalent to the statement with the parentheses removed
 Motivation
 ==========
 
-Is a common user mistake when using the form of the assert stamens that includes
-the error message to surround it by parentheses. Unfortunately, this mistake
-passes undetected as the assert will always pass due the the fact that is
+It is a common user mistake when using the form of the assert statement that includes
+the error message to surround it with parentheses. Unfortunately, this mistake
+passes undetected as the assert will always pass, because it is
 interpreted as an assert statement where the expression is a two-tuple, which
 always has truth-y value.
 
-The mistake most often happens when extending thing or description beyond a
-single line on assert statements as () are the natural way to do that and as it
-is with assert being a statement.
+The mistake most often happens when extending the test or description beyond a
+single line, as parentheses are the natural way to do that.
 
 This is so common that a ``SyntaxWarning`` is `now emitted by the compiler
 <https://bugs.python.org/issue35029>`_.
 
 Additionally, some other statements in the language allow parenthesized forms
-in one way or another like ``import`` statements (``from x import (a,b,c)``), ``del``
-statements (``del (a,b,c)``).
+in one way or another like ``import`` statements (``from x import (a,b,c)``) and
+``del`` statements (``del (a,b,c)``).
 
 Allowing parentheses not only will remove the common mistake but also will allow
 users and auto-formatters to format long assert statements over multiple lines
@@ -65,13 +64,13 @@ the formatting of other grammar constructs::
       "message",
   )
 
-This change have been originally discussed and proposed in [bpo-46167]_.
+This change has been originally discussed and proposed in [bpo-46167]_.
 
 Rationale
 =========
 
 This change can be implemented in the parser or in the compiler. We have
-selected implementing this change in the parser because doing in in the compiler
+selected implementing this change in the parser because doing it in the compiler
 will require re-interpreting the AST of an assert statement with a two-tuple::
 
   Module(
@@ -94,16 +93,16 @@ as the AST of an assert statement with an expression and a message::
       type_ignores=[])
 
 The problem with this approach is that the AST of the first form will
-technically be "incorrect" as we already have an specialized form for the AST of
-an assert statement with an expression and a message (the second one). This
+technically be "incorrect" as we already have a specialized form for the AST of
+an assert statement with a test and a message (the second one). This
 means that many tools that deal with ASTs will need to be aware of this change
 in semantics, which will be confusing as there is already a correct form that
 better expresses the new meaning.
 
 Specification
 =============
 
-This PEP proposes changing the grammar from the ``assert`` statement to: ::
+This PEP proposes changing the grammar of the ``assert`` statement to: ::
 
     | 'assert' '(' expression ',' expression [','] ')' &(NEWLINE | ';')
     | 'assert' a=expression [',' expression ]
@@ -124,11 +123,11 @@ The change is not technically backwards compatible, as parsing ``assert (x,y)``
 is currently interpreted as an assert statement with a 2-tuple as the subject,
 while after this change it will be interpreted as ``assert x,y``.  
 
-On the other hand, this kind of assert statements are always true so they are
+On the other hand, assert statements of this kind always pass, so they are
 effectively not doing anything in user code. The authors of this document think
 that this backwards incompatibility nature is beneficial, as it will highlight
 these cases in user code while before they will have passed unnoticed (assuming that
-these cases still exist is because users are ignoring syntax warnings).
+these cases still exist because users are ignoring syntax warnings).
 
 Security Implications
 =====================