FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

bpo-40334: Add What's New sections for PEP 617 and PEP 585 by gvanrossum · Pull Request #19704 · python/cpython · GitHub

  1. python
  2. cpython

Repository navigation

bpo-40334: Add What's New sections for PEP 617 and PEP 585 #19704

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.

Sign up for GitHub

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

Merged
gvanrossum merged 1 commit into from
Apr 25, 2020
Conversation 3 Commits 1 Checks 0 Files changed
Merged

bpo-40334: Add What's New sections for PEP 617 and PEP 585 #19704

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension .rst  (1) All 1 file type selected
Viewed files
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Unified
Split
Hide whitespace
Diff view
Unified
Split
Hide whitespace
43 changes: 43 additions & 0 deletions Doc/whatsnew/3.9.rst
Show comments
View file
Open in desktop
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Original file line number Diff line number Diff line change
Expand Up @@ -115,6 +115,49 @@ to easily remove an unneeded prefix or a suffix from a string. Corresponding
added. See :pep:`616` for a full description. (Contributed by Dennis Sweeney in
:issue:`18939`.)

PEP 585: Builtin Generic Types
------------------------------

In type annotations you can now use built-in collection types such as
``list`` and ``dict`` as generic types instead of importing the
corresponding capitalized types (e.g. ``List`` or ``Dict``) from
``typing``. Some other types in the standard library are also now generic,
for example ``queue.Queue``.

Example:

.. code-block:: python

def greet_all(names: list[str]) -> None:
for name in names:
print("Hello", name)

See :pep:`585` for more details. (Contributed by Guido van Rossum,
Ethan Smith, and Batuhan Taşkaya in :issue:`39481`.)

PEP 617: New Parser
-------------------

Python 3.9 uses a new parser, based on `PEG
<https://en.wikipedia.org/wiki/Parsing_expression_grammar>`_ instead
of `LL(1) <https://en.wikipedia.org/wiki/LL_parser>`_. The new
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.

ambv Apr 24, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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.

gvanrossum Apr 24, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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.

ambv Apr 24, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

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

The :mod:`ast` module uses the new parser and produces the same AST as
the old parser.

In Python 3.10, the old parser will be deleted and so will all
functionality that depends on it (primarily the :mod:`parser` module,
which has long been deprecated). In Python 3.9 *only*, you can switch
back to the LL(1) parser using a command line switch (``-X
oldparser``) or an environment variable (``PYTHONOLDPARSER=1``).

See :pep:`617` for more details. (Contributed by Guido van Rossum,
Pablo Galindo and Lysandros Nikolau in :issue:`40334`.)


Other Language Changes
======================
Expand Down
Back | FazBrowse Home | New Git URL