PEP 617: minor edits (#1355)

pep-0617.rst

@@ -69,7 +69,7 @@ Syntax Tree (CST) sometimes known directly as a "parse tree". In this process, t
 *first sets* are used indirectly when generating the DFAs.
 
 LL(1) parsers and grammars are usually known for being efficient and simple to
-implement and generate the but the reality is that expressing some constructs
+implement and generate, but the reality is that expressing some constructs
 currently present in the Python language is notably difficult or impossible with
 such a restriction. As LL(1) parsers can only look one token ahead to distinguish
 possibilities, some rules in the grammar may be ambiguous. For instance the rule::
@@ -131,7 +131,7 @@ Notice that "failure" results do not imply that the program is incorrect or a
 parsing failure because as the choice operator is ordered, a "failure" result
 merely indicates "try the following option". A direct implementation of a PEG
 parser as a recursive descent parser will present exponential time performance in
-the worst case as compared with LL(1) parsers, PEG parsers have infinite lookahead
+the worst case as compared with LL(1) parsers, because PEG parsers have infinite lookahead
 (this means that they can consider an arbitrary number of tokens before deciding
 for a rule). Usually, PEG parsers avoid this exponential time complexity with a
 technique called "packrat parsing" [1]_ which not only loads the entire
@@ -246,7 +246,7 @@ pipelines, in CPython this intermediate CST is not used by anything else (it is
 only indirectly exposed by the *parser* module and a surprisingly small part of
 the code in the CST production is reused in the module). Which is worse: the whole
 tree is kept in memory, keeping many branches that consist of chains of nodes with
-a single child. This has shown to consume a considerable ammount of memory (for
+a single child. This has been shown to consume a considerable ammount of memory (for
 instance in `bpo-26451: Excessive peak memory consumption by the Python
 parser <https://bugs.python.org/issue26415>`_).
 
@@ -612,12 +612,12 @@ initially to fallback to the previous parser if needed:
     and ``compile`` will use the parser set by the flags or the environment variable and
     the default parser will be the current parser.
 
-2.  After Python 3.9 Beta 1 the default parser will be the new parser.
+2.  After Python 3.9 beta 1 the default parser will be the new parser.
 
 3.  Between Python 3.9 and Python 3.10, the old parser and related code (like the
     "parser" module) will be kept until a new Python release happens (Python 3.10). In
     the meanwhile and until the old parser is removed, **no new Python Grammar
-    addition will be added that requires the peg parser**. This means that the grammar
+    addition will be added that requires the PEG parser**. This means that the grammar
     will be kept LL(1) until the old parser is removed.
 
 4.  In Python 3.10, remove the old parser, the command-line flag, the environment