Python 3 中不会改变的事情（PEP 3099）

概要

有些想法很糟糕。尽管关于 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

版权