python 3在語義上版本化和向前兼容

Question

我正在研究一些希望引入 Python 3.6 以在 3.5 為標准的環境中使用的軟件。 閱讀 Python 的文檔，我找不到任何關於以下內容的信息：

• 3.5 代表一個語義版本號
• 3.6 代表向前兼容升級（即：為 3.5 運行時編寫的代碼保證在 3.6 運行時中工作）

這個關於移植到 3.7 的頁面存在這一事實讓我強烈認為不，但我看不到關於版本號含義的官方文檔（如果有的話，ala Linux 內核版本控制）

在更一般的意義上 - 在 3.X 版本流中是否有關於兼容性標准的 PEP？

Answer 1

簡短的回答是“不”，長的回答是“他們爭取接近它的東西”。

通常，微版本匹配語義版本控制規則； 他們不應該破壞任何東西或添加功能，只是修復錯誤。 情況並非總是如此（例如， 3.5.1 在namedtuple上破壞了vars() ，因為它導致了一個比中斷出現時更糟糕的錯誤），但是對於代碼來說這是非常罕見的（尤其是 Python 級別的東西，如與 C 擴展相反）以突破微邊界。

次要版本主要是“添加功能”，但它們也會根據事先警告做出向后不兼容的更改。 例如， async和await在 Python 3.7 中成為關鍵字，這意味着將它們用作變量名的代碼已損壞，但啟用警告后，您會在 3.6 中看到DeprecationWarning 。 許多語法更改最初是作為來自特殊__future__模塊的可選導入引入的，並記錄了成為默認行為的時間表。

在次要版本中所做的更改都不是廣泛的更改； 我懷疑任何單獨的棄用或語法更改是否會影響甚至 1% 的現有源代碼，但它確實發生了。 如果您有一百個第三方依賴項，並且您要跳過一兩個次要版本，則其中一個很可能會被更改破壞（例如： 0.12之前的pika使用async作為變量名稱，並在 Python 3.7 上中斷；他們發布了修復該錯誤的新版本，但當然，從0.11及更低版本到0.12及更高版本更改了他們自己的 API，可能會破壞您的代碼）。

主要版本大致如您所料； 預期/允許向后不兼容的更改（盡管它們通常不是輕率的；更改越大，好處越大）。

重點是，它接近語義版本控制，但為了不每隔幾年發布一次大版本，同時也不會因為嚴格的兼容性限制而讓語言停滯不前，只要有小版本就可以破壞少量現有代碼是警告（通常以使用已棄用行為的代碼發出的實際警告的形式，關於新功能文檔的注釋，以及有時__future__支持以簡化遷移路徑）。

這在他們的開發周期文檔中都有正式記錄（細節略少）：

為了澄清術語，Python 使用major.minor.micro命名法來表示生產就緒版本。 因此，對於 Python 3.1.2 final，即主要版本為 3，次要版本為 1，微型版本為 2。

• 新的主要版本是例外； 它們僅在認為有必要進行強烈不兼容的更改並且提前很長時間計划時才會出現；
• 新的次要版本是功能發布； 它們每年從當前的開發分支中發布；
• 新的微版本是錯誤修復版本； 他們大約每 2 個月獲釋一次； 它們是在維修部門准備的。

Answer 2

這是關於更新到 3.6 的文檔。

例如，如果您在 3.5 中的代碼中有open(apath, 'U+') ，那么它會在 3.6 中失敗。 因此，很明顯，Python 3.6 並不完全向后兼容 3.5 中的所有用法。

實際上，您將需要進行測試，盡管我很自在地告訴幾乎所有領域的普通 stackoverflow 讀者，他們應該對進行此升級感到自在。

至於語義版本控制，具體來說，Python 並不遵循它，但它並不完全不知道主要、次要和錯誤修復版本的含義。 可以在此處找到針對其開發人員的 Python 指南。

為了澄清術語，Python 使用major.minor.micro 命名法來表示生產就緒版本。 因此，對於 Python 3.1.2 final，即主要版本為 3，次要版本為 1，微型版本為 2。

• 新的主要版本是例外； 它們僅在認為有必要進行強烈不兼容的更改並且提前很長時間計划時才會出現；
• 新的次要版本是功能發布； 它們每年從當前的開發分支中發布；
• 新的微版本是錯誤修復版本； 他們大約每 2 個月獲釋一次； 它們是在維修部門准備的。

另請閱讀PEP440 ，它是針對模塊的，與發布新版本的 python 本身無關，但仍然與生態系統的哲學相關。