[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Slow down...

On 5/7/2018 7:59 AM, Eric Snow wrote:
> On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan <ncoghlan at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180507/91dffb58/attachment.html>