PEP 617: Change migration plan; default to pegen in 3.9a6 (#1369)

This commit is contained in:
Lysandros Nikolaou 2020-04-16 02:31:38 +03:00 committed by GitHub
parent 3c1b60c158
commit 68c54982c4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 8 deletions

View File

@ -650,22 +650,20 @@ This section describes the migration plan when porting to the new PEG-based pars
if this PEP is accepted. The migration will be executed in a series of steps that allow
initially to fallback to the previous parser if needed:
1. Before Python 3.9 beta 1, include the new PEG-based parser machinery in CPython
1. Starting with Python 3.9 alpha 6, include the new PEG-based parser machinery in CPython
with a command-line flag and environment variable that allows switching between
the new and the old parsers together with explicit APIs that allow invoking the
new and the old parsers independently. At this step, all Python APIs like ``ast.parse``
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 new PEG-based parser.
2. Starting with 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
2. 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
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
3. In Python 3.10, remove the old parser, the command-line flag, the environment
variable and the "parser" module and related code.
==========================
@ -686,8 +684,8 @@ produced by the standard compiler. (In the process we found a few bugs
in the standard parser's treatment of line and column numbers, which
we have all fixed upstream via a series of issues and PRs.)
We have also occasionally compiled a much larger codebase (the 100
most popular packages on PyPI) and this has helped us find a (very)
We have also occasionally compiled a much larger codebase (the approx.
3800 most popular packages on PyPI) and this has helped us find a (very)
few additional bugs in the new parser.
(One area we have not explored extensively is rejection of all wrong