On 5/7/2018 7:59 AM, Eric Snow wrote:
On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncogh...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
