今年1月1日，Python 2代碼庫被凍結。從那天起，不再有Python 2進一步的向后移植（backport），實際上使這種語言及運行時環(huán)境成了過時的技術。核心開發(fā)人員Nick Coghlan在FAQ中解釋道，因而結束了“核心開發(fā)團隊為參考解釋器同時維護Python 2和3長達約13年”的局面。

Python 2的最終版現(xiàn)正通過beta測試版和發(fā)行候選版階段，預計最后一個生產級版本Python 2.7.18會在2020年4月推出。

雖然Python社區(qū)中的大多數(shù)人一致認為Python需要大刀闊斧的改動——尤其是由于迫切需要的、早就該有的統(tǒng)一碼（Unicode）支持。但是Python 2代碼運行得好好的許多人頗感沮喪。有關這種遷移的真實故事在網上比比皆是，領導遷移工作的開發(fā)人員更是有話要說。

遷移故事

Chris Siebenmann上周巧妙地總結了一些挫折感，他的Twitter個人資料顯示他是一名“過于投入的系統(tǒng)管理員”。

Siebenmann在一篇博文中寫道“沒必要維護就可以運行的實用代碼是一種資產；它就在那里，處理有價值的任務，不需要你做任何工作。為了不破壞系統(tǒng)（而不是添加任何功能）而必須做大量工作的代碼是一種包袱；你得做一番工作，還引入了風險，卻一無所獲。”

但是他的處境沒有博得云/ AI架構師Phil Rhodes的多少同情，后者創(chuàng)辦了Fogbeam Labs，這家公司生產開源企業(yè)軟件，他在Hacker News網站上提出了相左的觀點?！按蠹s12年來，人們始終知道需要開始遷離Python 2。如果你現(xiàn)在因Python 2即將消失而感到恐慌，很難不問‘你之前在等什么？’”

大公司同樣面臨遷移方面的挑戰(zhàn)。LinkedIn的高級軟件工程師Barry Warsaw還是自上世紀90年代中期以來的Python指導委員會成員和Python核心開發(fā)人員，他在博文中描述了“在完成大概兩個季度的規(guī)劃和兩個季度的執(zhí)行之后”，LinkedIn為完成代碼庫的遷移開展了曠日持久的“橫跨多個季度的工作”。

開發(fā)團隊先在圖上列出了諸依賴項以確定工作優(yōu)先級——列出了75個“基礎性”存儲庫，然后創(chuàng)建了內部庫的“雙語”版本（可以使用Python 2或Python 3）。

Warsaw提到多個團隊和部門的工作時寫道：“這項工作需要共遷移約550個代碼存儲庫（庫、應用程序和服務）?！背嗣嫦蛴脩舻姆胀?#xff0c;LinkedIn還在內部使用Python用于持續(xù)集成/持續(xù)交付（CI/CD）框架、命令行接口以及部署和數(shù)據(jù)科學工具，這種散亂的非整體式環(huán)境用Warsaw的話來說“包括數(shù)百種獨立的微服務和工具，外加幾十個支持庫，它們都歸分管不同存儲庫的獨立團隊擁有。”

但是并非所有人都感到很高心。1月份，開發(fā)人員Wayne Rowcliffe在Hacker News上發(fā)帖稱其工作場所終于“快要完成遷移到Python 3的工作”。

“這項工作的最終結果是，上周我花了很大一部分時間來審核有70000行代碼變更的合并請求（pull request），這是去年秋天進來的大約1萬行變更請求中的最后一個合并請求。這一切都是我一位同事的杰作，他那無人羨慕的任務是梳理我們的整個代碼庫，以確定‘這是統(tǒng)一碼。這是字節(jié)。這是我們需要編碼/解碼的API邊界’等等?！?/p>

“那是噩夢般的工作，很高興我們捱過來了?！?/p>

他在后來的評論中將策略歸結為9個字?！拔覀冞\行了代碼檢查工具和測試套件，直到一切都過關。只是這時你面臨100萬行代碼，要花不少的時間。”

Mercurial的見解

另一番批評來自舊金山的開發(fā)人員Gregory Szorc，他是Mercurial版本控制工具的維護者。Mercurial與Python社區(qū)關系密切——Python一直使用Mercurial作為其存儲庫，但在2016年改用了Git。不過Szorc在一篇博文中描述了Mercurial在2019年11月5日努力獲得Python 3支持時所得到的體會，他對來自Python語言內部的瓶頸提出了一番批評。

他寫道：“該項目在Python 3移植版方面起步很晚，主要歸因于Python 2.4和2.5兼容性阻礙了我們。我們放棄了對Python 2.6的支持。這極大地降低了支持Python 3的復雜性，因為Python 2.7中有大量的功能使得更容易既面向Python 2又面向Python 3，而現(xiàn)在我們的手沒有被綁住，可以使用它。”

但令人驚訝的是，Szorc稱，甚至Python 3版本之間存在一些變化（“我們不得不糊上墻紙”），這在2019年中期的“沖刺階段”中顯露出來。雖然Python 3.7的錯誤最少，但是“我們不得不花另外的精力使Python 3.5和3.6以及3.7正常運行。Python 3.8也一樣?！?/p>

很快，Mercurial迎來了遷移的重大日子。在持續(xù)集成系統(tǒng)（使用亞馬遜的AWS DynamoDB、S3和EC2競價型實例用于執(zhí)行作業(yè)）上，Szorc開始在Linux上測試Python版本3.5、3.6、3.7和3.8（并在Windows上測試Python 3.7）。但是雖然通過了所有測試，“我認為交付只是漫長過程中的一塊里程碑——大概是最重要的里程碑。仍有很多工作要做……我們的用戶可能多年后會在Python 3上發(fā)現(xiàn)各種bug?！?/p>

Windows上仍然存在“少數(shù)的已知問題”。

這次經歷讓Szorc感到一些不快。Szorc寫道：“雖然過去我喜愛Python——從這種語言到受人歡迎的社區(qū)，還是搞不明白Python如何因當初選擇了遷移計劃而給整個社區(qū)帶來如此多的困難和麻煩。我認為Python的選擇是一個反面典例，表明了在管理大型項目或生態(tài)系統(tǒng)時不該做什么。如果花時間來了解和反思Python的失誤，其他廣泛部署系統(tǒng)的維護者將受益匪淺……”

“Python 3的最初方法反映了許多開發(fā)人員和項目所犯的愚蠢行為：嘗試重寫而不是執(zhí)行漸進式演變。對于既有的項目，大規(guī)模重寫常常效果不佳。而Python 3也不例外?！?/p>

其他見解

Szorc的博文出現(xiàn)在Hacker News上后吸引了400多人點贊，另有339條留言，包括一位持不同意見的紐約市軟件工程師?！拔覅⑴c了多年來以同樣的代碼庫支持python2和python3的多個重要的庫和框架……而其實并不是這樣的……是的，你幾乎不得不等待python-3.4即將發(fā)布、等待python-2.6基本上退役，改而使用python-2.7。隨后從2014年初開始，使干凈的代碼庫與python-2.7和python-3.4 +兼容顯得非常簡單?！?/p>

夏威夷大學的一名學生認為，人們對一款名為2to3的遷移程序寄予太高的期望，該程序試圖提供一個自動代碼翻譯器。有人在回復時抱怨道：“Python 2到3的遷移計劃根本行不通。他們以為所有人會大規(guī)模運行2to3，然后幾年后我們所有人都會切換到3?！?/p>

“相反拖了十多年，因為實際上我們需要編寫與Python 2和3都兼容的代碼……直到足夠的代碼使用3、放棄對2的支持。”

而一些人質疑這項工作所取得的成果。華盛頓的電氣工程師Brian Davis自稱是“老派的Web開發(fā)人員”，他在將“許多”小項目轉換到Python 2之后分享了其想法?！白址幚矸矫娴淖兓盐译y住了，相對導入方面的變化也頗費一番思量。但是最挫折的是這個棘手的問題：我干嘛這么做？”

另外見解

從一些方面來看，Python 2沒有真正消失。比如有Tauthon，Python 2.7.17解釋器的這個向后兼容分支有新的語法，以及從Python 3.x向后移植的庫。Tauthon可以運行Python 2.7代碼和C擴展以及來自Python 3.x的一些新功能。

除了Python Package Index中所列的第三方開源軟件包外，開發(fā)工具公司ActiveState還為Python 2及其標準庫提供商業(yè)支持。

不過，大多數(shù)開發(fā)人員現(xiàn)置身于Python 3時代。但到頭來，也許正是默默付出的艱辛工作400多位匿名人士點贊Szorc撰寫的那篇博文。他的博文寫道：“移植到Python 3所需的工作量驚人。對于Mercurial來說，Python 3帶來了一大堆問題，好多問題其實解決不了?！?/p>

他寫道：“稱Python 3遷移項目具有破壞性、讓人分心并不過分。作為項目維護者，很自然地會問如果不強迫我們做這件次要的事情，我們本可以取得什么樣的成就?！?/p>

原文鏈接：Python 3 遷移怨聲載道_工作

總結

以上是生活随笔為你收集整理的两个git库之间迁移_Python 3 迁移怨声载道的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。