From e980d4e3239e59df86a283fdece19a8512e08f19 Mon Sep 17 00:00:00 2001 From: Jelle Zijlstra Date: Wed, 1 Apr 2020 13:59:32 -0700 Subject: [PATCH] PEP 617: minor edits (#1355) --- pep-0617.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/pep-0617.rst b/pep-0617.rst index e4cb8248d..1f0cd6058 100644 --- a/pep-0617.rst +++ b/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 `_). @@ -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