Python 如何移除旧的版本特性，如何迎接新的特性？

2020 年 4 月 20 日，Python 2 的最后一个版本 2.7.18 发布了，这意味着 Python 2 是真正的 EOL（end of life）了，一个时代终于落幕了。

Python 2.0 版本是在 2000 年发布的，至今正好到 20 周年（差半年），一代版本竟然持续了这么长时间。其中，2.7 版本是在 Python 3 推出后才发布的，它在 2010 年发布，至今已是 10 年之久。

事实上，Python 诞生了 30 年，但版本演进过程一直很慢，目前最新发布的版本只到 3.8.2。

对比一下相差几岁的隔壁家选手，C++ 已经发展到了 20，JAVA 发展到了 14 ，PHP 到了 7.4，差距悬殊。

但是，版本发布太频繁，也不总是一件好事。就在 Python 程序员抱怨自己的 Python 2 项目还没升 3 版本时，有些 JAVA 程序员还在维护 6、7 版本的项目呢。版本迁移之苦，大家彼此彼此，五十步笑百步。

编程语言跨版本间出现不兼容的特性，几乎是常态。很多时候，并不是说过去的设计是 bug，只是因为编程语言也是某种“生命体”，它会学习其它语言，也会自我进化，所以就有新陈代谢。

摆脱旧的不兼容性版本或者某些落后的设计，有时候需要挺漫长的过渡期。为了方便程序员迁移，核心开发者们形成了一些有效的惯例。

以 Python 为例，我知道有以下的几种策略：

1、DeprecationWarning 提示

当使用过期的类或方法时，会出现 DeprecationWarning 告警。

例如，从 collections 模块导入 ABC（Abstract Base Classes，即抽象基类）就是过期用法，会出现以下提示：

DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working

从 3.3 版本起，正确的用法是from collections.abc import Iterable，直到 3.9 版本时，会取消过期提示，出现报错。

2、将模块改名，约定为私有

在 Python 中，以单下划线“_”开头命名的变量，会被约定为私有的。如果在一个模块中定义了私有变量，理论上它就不该被导出到其它模块使用。

这种命名方式也被推广到了标准模块上。例如，在 Python 的极早期版本中有一个thread 模块，后来到 1.5.1 版本，以 thread 为基础又推出一个更方便好用的threading 模块，也就是我们熟知的实现多线程的模块。

为了摆脱/屏蔽旧的实现，Python 把 thread 模块重命名为_thread ，约定为私有的，这种方式很灵活，普通程序员不会感知它的存在，骨灰级程序员却可以用它实现更加低层的开发。

3、文档中作 deprecated 提示

它跟 DeprecationWarning 是同样的意思。之所以要单独列出来，是因为在构思本文时，我正巧在 Python 3.8 文档中发现了一则提示，忍不住分享一下。

文档中说：@asyncio.coroutine 装饰器不再支持基于yield from 生成器实现的协程，需要显式地写成“asyc def”这种定义方式。

这意味着，3.8 版本对该特性来说就是个分界线，它将进入一个平稳的淘汰周期。

以上三种方式可谓是“除旧”，是面向过去的版本所做的。与它们相对应，就少不了“迎新”的过程，要面向未来的版本。

Python 中有时候会在当前版本中加入一些实验性的特性，期待在未来版本中再完全地实现。而这，就需要给程序员们指出一些过渡性的提示。

例如，在《Python 3.9 性能优化：更快的 list()、dict() 和 range() 等内置类型》一文中，我就介绍了隐藏在 3.8 版本中的“vectorcall”协议，它要在 3.9 版本中才会真正地实现（而且不排除在未来还会继续扩展）。

此外，还有一个很著名的例子：3.2 版本中推出的 concurrent.futures标准库（依据 PEP-3148）。

这是一个统合了多线程与多进程的异步开发库，“concurrent”指的是并发，而“并发”概念可以囊括多线程与多进程的实现方式。

为什么在“concurrent”下面要加一个“futures”呢？PEP-3148 中指出了这样命名的三点原因，其中最后一点是：希望在将来（in the future）能够添加和移动现有的跟并发相关的库到concurrent库下面。

也就是说，3.2 版本的concurrent.futures就是一种实验性的设计，它是为将来更好的concurrent库而作的准备。虽然说将来的最终实现，可能跟 PEP 中设想的不同，但是，这种面向将来的长远考虑的设计思路，会给整个社区带来某种预期和共同的信念。

好了，聊了这么多，是时候收个尾了。

我从未真正开发或维护过 Python 2 的项目，所以在这个本应纪念它 EOL 的日子，所能想到的就是一个更具普遍性的“除旧迎新”的话题：旧的版本特性是如何逐步退出的，新的版本特性又是如何逐步加入的？