💻 工作🐍PythonPEP
Source
Edit
History

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

文章目录
  1. 1. 概要
  2. 2. 语言核心
  3. 3. 内置对象
  4. 4. 标准类型
  5. 5. 编码风格
  6. 6. 交互式解释器
  7. 7. 版权
  8. 8. 译者注

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

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

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

PEP 原文： https://www.python.org/dev/peps/pep-0399

PEP 标题： Things that will Not Change in Python 3000

PEP 作者： Georg Brandl

创建日期： 2006-04-04

译者：豌豆花下猫（Python 猫 公众号作者）

翻译计划：https://github.com/chinesehuazhou/peps-cn

概要

有些想法很糟糕。尽管关于 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。实际指的是“邮件列表中的议题”，为简洁起见，省译为“邮件”。