On 5/7/2018 7:59 AM, Eric Snow wrote:

On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:

I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003
language moratorium could be a very good idea.

Note that the PEP specifically applies to "syntax, semantics, and
built-ins".  Here's the full abstract [1]:

    This PEP proposes a temporary moratorium (suspension) of all changes to the
    Python language syntax, semantics, and built-ins for a period of
at least two
    years from the release of Python 3.1. In particular, the moratorium would
    include Python 3.2 (to be released 18-24 months after 3.1) but allow Python
    3.3 (assuming it is not released prematurely) to once again include language
    changes.

    This suspension of features is designed to allow non-CPython implementations
    to "catch up" to the core implementation of the language, help ease adoption
    of Python 3.x, and provide a more stable base for the community.

-eric

Here's my "lightning" response to a "lightning talk" about a moratorium:

So if other implementations didn't catch up during the last moratorium, either the moratorium then was lifted too soon, or the other implementations don't really want to catch up, or the thought that they should catch up was deemed less important than making forward progress with the language. Have any of those opinions changed?

While async is a big change that I personally haven't grasped, but which has little impact (a couple keywords) on code that doesn't use it, a new moratorium wouldn't impact it, and nothing else that is happening seems too much or too fast from my perspective.

Dan's original comment about language versus library is interesting, though. It is probably true that one should resist adding language where library suffices, but sometimes a lack of certain expressiveness in the language causes cumbersome implementations of library routines to achieve the goal.

f-strings and binding expressions are cases where (1) the functionality is certainly possible via library (2) there is a large amount of code that uses the functionality, and (3) said code is more cumbersome without the expressiveness of the newer syntax.