2020 年 4 月 20 日，Python 2 的最后一個(gè)版本 2.7.18 發(fā)布了，這意味著 Python 2 是真正的 EOL（end of life）了，一個(gè)時(shí)代終于落幕了。

Python 2.0 版本是在 2000 年發(fā)布的，至今正好到 20 周年（差半年），一代版本竟然持續(xù)了這么長(zhǎng)時(shí)間。其中，2.7 版本是在 Python 3 推出后才發(fā)布的，它在 2010 年發(fā)布，至今已是 10 年之久。

 

事實(shí)上，Python 誕生了 30 年，但版本演進(jìn)過程一直很慢，目前最新發(fā)布的版本只到 3.8.2。

對(duì)比一下相差幾歲的隔壁家選手，C++ 已經(jīng)發(fā)展到了 20，JAVA 發(fā)展到了 14 ，PHP 到了 7.4，差距懸殊。

但是，版本發(fā)布太頻繁，也不總是一件好事。就在 Python 程序員抱怨自己的 Python 2 項(xiàng)目還沒升 3 版本時(shí)，有些 JAVA 程序員還在維護(hù) 6、7 版本的項(xiàng)目呢。版本遷移之苦，大家彼此彼此，五十步笑百步。

編程語言跨版本間出現(xiàn)不兼容的特性，幾乎是常態(tài)。很多時(shí)候，并不是說過去的設(shè)計(jì)是 bug，只是因?yàn)榫幊陶Z言也是某種“生命體”，它會(huì)學(xué)習(xí)其它語言，也會(huì)自我進(jìn)化，所以就有新陳代謝。

擺脫舊的不兼容性版本或者某些落后的設(shè)計(jì)，有時(shí)候需要挺漫長(zhǎng)的過渡期。為了方便程序員遷移，核心開發(fā)者們形成了一些有效的慣例。

以 Python 為例，我知道有以下的幾種策略：

1、DeprecationWarning 提示

當(dāng)使用過期的類或方法時(shí)，會(huì)出現(xiàn) DeprecationWarning 告警。

例如，從 collections 模塊導(dǎo)入 ABC（Abstract Base Classes，即抽象基類）就是過期用法，會(huì)出現(xiàn)以下提示：

 

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 版本時(shí)，會(huì)取消過期提示，出現(xiàn)報(bào)錯(cuò)。

2、將模塊改名，約定為私有

在 Python 中，以單下劃線“_”開頭命名的變量，會(huì)被約定為私有的。如果在一個(gè)模塊中定義了私有變量，理論上它就不該被導(dǎo)出到其它模塊使用。

這種命名方式也被推廣到了標(biāo)準(zhǔn)模塊上。例如，在 Python 的極早期版本中有一個(gè)thread 模塊，后來到 1.5.1 版本，以 thread 為基礎(chǔ)又推出一個(gè)更方便好用的threading 模塊，也就是我們熟知的實(shí)現(xiàn)多線程的模塊。

為了擺脫/屏蔽舊的實(shí)現(xiàn)，Python 把 thread 模塊重命名為_thread ，約定為私有的，這種方式很靈活，普通程序員不會(huì)感知它的存在，骨灰級(jí)程序員卻可以用它實(shí)現(xiàn)更加低層的開發(fā)。

 

3、文檔中作 deprecated 提示

它跟 DeprecationWarning 是同樣的意思。之所以要單獨(dú)列出來，是因?yàn)樵跇?gòu)思本文時(shí)，我正巧在 Python 3.8 文檔中發(fā)現(xiàn)了一則提示，忍不住分享一下。

文檔中說：@asyncio.coroutine 裝飾器不再支持基于yield from 生成器實(shí)現(xiàn)的協(xié)程，需要顯式地寫成“asyc def”這種定義方式。

 

這意味著，3.8 版本對(duì)該特性來說就是個(gè)分界線，它將進(jìn)入一個(gè)平穩(wěn)的淘汰周期。

以上三種方式可謂是“除舊”，是面向過去的版本所做的。與它們相對(duì)應(yīng)，就少不了“迎新”的過程，要面向未來的版本。

Python 中有時(shí)候會(huì)在當(dāng)前版本中加入一些實(shí)驗(yàn)性的特性，期待在未來版本中再完全地實(shí)現(xiàn)。而這，就需要給程序員們指出一些過渡性的提示。

例如，在《Python 3.9 性能優(yōu)化：更快的 list()、dict() 和 range() 等內(nèi)置類型》一文中，我就介紹了隱藏在 3.8 版本中的“vectorcall”協(xié)議，它要在 3.9 版本中才會(huì)真正地實(shí)現(xiàn)（而且不排除在未來還會(huì)繼續(xù)擴(kuò)展）。

此外，還有一個(gè)很著名的例子：3.2 版本中推出的 concurrent.futures標(biāo)準(zhǔn)庫(kù)（依據(jù) PEP-3148）。

這是一個(gè)統(tǒng)合了多線程與多進(jìn)程的異步開發(fā)庫(kù)，“concurrent”指的是并發(fā)，而“并發(fā)”概念可以囊括多線程與多進(jìn)程的實(shí)現(xiàn)方式。

為什么在“concurrent”下面要加一個(gè)“futures”呢？PEP-3148 中指出了這樣命名的三點(diǎn)原因，其中最后一點(diǎn)是：希望在將來（in the future）能夠添加和移動(dòng)現(xiàn)有的跟并發(fā)相關(guān)的庫(kù)到concurrent庫(kù)下面。

也就是說，3.2 版本的concurrent.futures就是一種實(shí)驗(yàn)性的設(shè)計(jì)，它是為將來更好的concurrent庫(kù)而作的準(zhǔn)備。雖然說將來的最終實(shí)現(xiàn)，可能跟 PEP 中設(shè)想的不同，但是，這種面向?qū)淼拈L(zhǎng)遠(yuǎn)考慮的設(shè)計(jì)思路，會(huì)給整個(gè)社區(qū)帶來某種預(yù)期和共同的信念。