Skip to content
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

Merged
merged 1 commit into from
Apr 25, 2020

Conversation

gvanrossum
Copy link
Member

@gvanrossum gvanrossum commented Apr 24, 2020

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.
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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 :-)

@gvanrossum gvanrossum merged commit 0e80b56 into master Apr 25, 2020
@gvanrossum gvanrossum deleted the whatsnew-617 branch April 25, 2020 00:19
CuriousLearner added a commit to CuriousLearner/cpython that referenced this pull request Apr 27, 2020
* '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)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants