-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-40334: Add What's New sections for PEP 617 and PEP 585 #19704
Conversation
parser's performance is roughly comparable to that of the old parser, | ||
but the PEG formalism is more flexible than LL(1) when it comes to | ||
designing new language features. We'll start using this flexibility | ||
in Python 3.10 and later. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there no new features that PEG allowed in the current state? Is this 100% 1:1 with the LL-1 parser?
One thing you might mention is why this work was done in the first place. "It's more flexible" isn't the entire truth. The truth is that Python's actual grammar even pre-3.9 was not really LL-1 anymore and the current parser overstayed its welcome, leading to tricky maintenance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are two Easter eggs; the new parser produces a syntax error if you use __new_parser__
(this is for us so we can ensure a code path is actually using the new parser), and it supports with (ctxmgr1 as var1, ctxmgr2 as var2, ...): block
. But I think neither should be documented (and maybe we should remove the latter during the beta cycle, before people start relying on it).
I'd prefer not to go into a long discussion about the "why" here, people can read the PEP. Honestly, it's hardly worth a mention in "what's new" except people need to be aware and we need to advertise the ways to disable it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should remove the latter during the beta cycle, before people start relying on it
Please no, that was one of the motivators behind me nagging you about this at the core sprint in 2017 and 2018 :-)
* 'master' of github.com:python/cpython: (2949 commits) Add files in tests/test_peg_generator to the install target lists (pythonGH-19723) bpo-40398: Fix typing.get_args() for special generic aliases. (pythonGH-19720) bpo-40348: Fix typos in the programming FAQ (pythonGH-19729) bpo-38387: Formally document PyDoc_STRVAR and PyDoc_STR macros (pythonGH-16607) bpo-40401: Remove duplicate pyhash.h include from pythoncore.vcxproj (pythonGH-19725) bpo-40387: Improve queue join() example. (pythonGH-19724) bpo-40396: Support GenericAlias in the typing functions. (pythonGH-19718) Fix typo in Lib/typing.py (pythonGH-19717) Fix typo in object.__format__ docs (pythonGH-19504) bpo-40275: Avoid importing logging in test.support (pythonGH-19601) bpo-40275: Avoid importing socket in test.support (pythonGH-19603) bpo-40275: Avoid importing asyncio in test.support (pythonGH-19600) bpo-40279: Add some error-handling to the module initialisation docs example (pythonGH-19705) closes bpo-40385: Remove Tools/scripts/checkpyc.py (pythonGH-19709) bpo-40334: Add What's New sections for PEP 617 and PEP 585 (pythonGH-19704) bpo-40340: Separate examples more clearly in the programming FAQ (pythonGH-19688) bpo-40360: Deprecate lib2to3 module in light of PEP 617 (pythonGH-19663) bpo-40334: Rewrite test_c_parser to avoid memory leaks (pythonGH-19694) bpo-38061: subprocess uses closefrom() on FreeBSD (pythonGH-19697) bpo-38061: os.closerange() uses closefrom() on FreeBSD (pythonGH-19696) ...
Also https://bugs.python.org/issue39481
https://bugs.python.org/issue40334