iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 617: minor edits (#1355)

This commit is contained in:
Jelle Zijlstra 2020-04-01 13:59:32 -07:00 committed by GitHub
parent 41657e2b48
commit e980d4e323
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
pep-0617.rst
View File

@ -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. *first sets* are used indirectly when generating the DFAs.
LL(1) parsers and grammars are usually known for being efficient and simple to 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 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 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:: 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 parsing failure because as the choice operator is ordered, a "failure" result
merely indicates "try the following option". A direct implementation of a PEG merely indicates "try the following option". A direct implementation of a PEG
parser as a recursive descent parser will present exponential time performance in 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 (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 for a rule). Usually, PEG parsers avoid this exponential time complexity with a
technique called "packrat parsing" [1]_ which not only loads the entire 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 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 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 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 instance in `bpo-26451: Excessive peak memory consumption by the Python
parser <https://bugs.python.org/issue26415>`_). 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 and ``compile`` will use the parser set by the flags or the environment variable and
the default parser will be the current parser. 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 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 "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 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. 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 4. In Python 3.10, remove the old parser, the command-line flag, the environment