Python 3 既是激进的又是克制的，这些提议被否决了

[译]PEP 3099--Python 3 中不会改变的事情

导语： Python 3.8 已经发布了，引进了很多变动点。关于 3.9 预计引入的修改，也披露了一些。咱们以前还关注过 GIL 的移除计划 和 Guido 正在开发的新解析器 等话题，这意味 Python 颇有活力，仍在健康地发展着。

Python 3 是比较大胆激进的，抛弃了前一版本的不少陈旧的包袱，但同时，它也是相对克制的（一直如此），社区里提出的不少提议都被否决了。前不久，我分享的Python 设计和历史的 27 个问题 提到了一些沉淀下来的设计问题，今天这篇译文则聚焦于官方明确否决掉的 24 个设计问题。

大部分问题都是细枝末节（例如大小写、括号、反引号、行宽等等），但细究起来的话，也会挺有意思，欢迎留言讨论。

---

PEP原文： https://www.python.org/dev/pe...
PEP标题： Things that will Not Change in Python 3000
PEP做者： Georg Brandl
建立日期： 2006-04-04
译者：豌豆花下猫（Python猫 公众号做者）
翻译计划：https://github.com/chinesehua...

---

目录

• 概要
• 语言核心
• 内置对象
• 标准类型
• 编码风格
• 交互式解释器
• 版权

概要

有些想法很糟糕。尽管关于 Python 演化的某些想法具备建设性，但很多想法却与 Python 的基本原则背道而驰，就像是让人围着圈跑步：哪也去不了，即便 Python 3000 容许提出特别的建议，也无论用。

此 PEP 尝试列出 Python 3000 上全部的 BDFL 决断，涉及那些不会发生更改的内容，以及不会引入的新功能，按主题排序，附加简短的说明或者 python-3000 邮件列表的相关线索。

若是你认为应该实现下面所列举的提议，那你最好当即离开计算机，出门去，尽情娱乐。去户外活动，在草地上打盹，都比提出一个“殴打一匹死马”的想法来得有建设性。这算是对你的警告（译注：下面的主意是不会实现的，不要试图改变这些已是板上钉钉的决断）。

语言核心

• Python 3000 不会区分大小写。
• Python 3000 不会从头开始重写。

不会使用 C++ 或其它不一样于 C 的语言做为实现语言。可是，代码库将逐渐迁移。Joel Spolsky 有一篇出色的文章解释了缘由： http://www.joelonsoftware.com/articles/fog0000000069.html

• self 不会变成隐式的。

使用显式的 self 是一个好事。消除解析变量时的歧义，可使得代码更清晰。这还使得函数和方法之间的差别变小。

邮件：“提议草案：Python 3.0 使用隐式的 self” https://mail.python.org/pipermail/python-dev/2006-January/059468.html

• lambda 不会被更名。

曾经有过提议，在 Python 3000 中移除 lambda。然而，没人可以提出更好的提供匿名函数的方法。因此 lambda 保留了下来。

但只是说要保持原样。（有人提议）增长它对语句的支持，但这不是一个好想法。由于它须要容许多行 lambda 表达式，这意味着多行表达式可能忽然出现，例如，将会容许对函数调用使用多行参数。那真是丑陋。

邮件：“genexp 语法/lambda”，https://mail.python.org/pipermail/python-3000/2006-April/001042.html

• Python 不会添加可编程的语法。

邮件：“是一个声明！是一个函数！二者皆是！”
https://mail.python.org/pipermail/python-3000/2006-April/000286.html

• 不会有相似 zip() 的并行迭代语法。

邮件：“并行迭代语法”， https://mail.python.org/pipermail/python-3000/2006-March/000210.html

• 字符串将保持可迭代。

邮件：“使字符串不可迭代”， https://mail.python.org/pipermail/python-3000/2006-April/000759.html

• 不会有对生成器表达式或列表推导式的结果进行排序的语法。sorted() 将涵盖全部的使用状况。

邮件：“为生成器表达式添加排序”， https://mail.python.org/pipermail/python-3000/2006-April/001295.html

• 切片和扩展型切片不会取消（即便__getslice__和__setslice__ API 可能被替换），它们也不会返回标准对象类型的视图。

邮件：切片的将来 https://mail.python.org/pipermail/python-3000/2006-May/001563.html

• 不会禁止在循环结构内重用循环变量。

邮件：消除迭代变量的做用域出血(scope bleeding) https://mail.python.org/pipermail/python-dev/2006-May/064761.html

• 解析器不会比 LL(1) 更复杂。

简单胜于复杂。这个想法适用于解析器。将 Python 的语法限制为 LL(1) 解析器是一种好处，而不是诅咒。它使咱们带上手铐，不至于发展过分，不至于最终获得些时髦的语法规则，像一些走向无名的动态语言那样，例如 Perl。

• 不会有括号。

这太明显了，以致于不须要引用邮件列表。使用 from __future__ import braces ，你就会获得关于这个问题的明确答案。

• 不会再有反引号。

反引号（`）将再也不用做 repr 的简写——但这并不意味着它们可用于其它用途。即便忽略向后兼容性的混乱，这字符自己也会引发太多问题（在某些字体、某些键盘上、在排版书籍时，等等）。

邮件：“使用反引号做为新运算符”，https://mail.python.org/pipermail/python-ideas/2007-January/000054.html

• 引用全局变量名 foo 不会被拼写为 globals.foo。global 语句会保留

邮件：“用全局内置对象替换 globals() 和 global 语句”， https://mail.python.org/pipermail/python-3000/2006-July/002485.html ，“显式词法做用域（pre-PEP?） ”， https://mail.python.org/pipermail/python-dev/2006-July/067111.html

• 不会有替代的绑定操做符，例如 := 。

邮件：“显式词法做用域（pre-PEP?）”， https://mail.python.org/pipermail/python-dev/2006-July/066995.html

• 咱们不会删除容器字面量。也就是说，{expr:expr, ...}，[expr, ...] 和(expr, ...)将保留。

邮件：“去除容器字面量”， https://mail.python.org/pipermail/python-3000/2006-July/002550.html：

• while 和 for 循环中的 else 子句不会更改语义，也不会被删除。

邮件：“ for/except/else 语法” https://mail.python.org/pipermail/python-ideas/2009-October/006083.html

内置对象

• zip() 不会增长关键字参数或其它机制来防止它在最短序列的末尾中止。

邮件：“对于不一样长度的序列，令 zip() 引起异常”， https://mail.python.org/pipermail/python-3000/2006-August/003338.html

• hash() 不会成为属性，由于属性应该是易于计算的，但哈希并不必定是这种状况。

邮件：“哈希做为属性/特性”， https://mail.python.org/pipermail/python-3000/2006-April/000362.html

标准类型

• 遍历字典将继续返回 key。

邮件：“遍历字典”， https://mail.python.org/pipermail/python-3000/2006-April/000283.html

邮件：让 iter(mapping) 生成 (key, value) 对https://mail.python.org/pipermail/python-3000/2006-June/002368.html

• 不会有 frozenlist 类型。

邮件：“不可变的列表”， https://mail.python.org/pipermail/python-3000/2006-May/002219.html

• int 不会支持下标来生成 range。

邮件：“ xrange vs.int .__ getslice__”， https://mail.python.org/pipermail/python-3000/2006-June/002450.html

编码风格

• 对于 C 和 Python 代码，（推荐的）最大行宽将保持 80 个字符。

邮件：“ C 风格指南”， https://mail.python.org/pipermail/python-3000/2006-March/000131.html

交互式解释器

• 解释器提示（>>>）不会改变。它给 Guido 带来温暖的模糊感受。

邮件：“低垂的果实：更改解释器的提示？”， https://mail.python.org/pipermail/python-3000/2006-November/004891.html

版权

本文档已放置在公共领域。源文档：
https://github.com/python/peps/blob/master/pep-3099.txt

译者注

文中出现的“邮件”，原文是“thread”，英文解释应该是：a series of connected messages on a message board on the Internet which have been sent by different people。实际指的是“邮件列表中的议题”，为简洁起见，省译为“邮件”。

公众号【Python猫】， 本号连载优质的系列文章，有喵星哲学猫系列、Python进阶系列、好书推荐系列、技术写做、优质英文推荐与翻译等等，欢迎关注哦。