Python 3是否语义化地版本化并支持向前兼容？

Question

我正在查看一些软件，该软件希望引入Python 3.6用于在3.5是标准的环境中使用。阅读Python文档后，我找不到任何关于以下内容的信息:

• 3.5是否代表语义版本号
• 3.6是否代表向前兼容升级（即：为3.5运行时编写的代码可保证在3.6运行时正常工作）

事实上，这篇有关升级至3.7的页面让我强烈地感觉这不可能，但我找不到有关版本号含义（如果有的话，类似于Linux内核版本）的官方文档。

就更普遍的意义而言 - 是否有PEP围绕3.X版本流中的兼容性标准？

- Andrew Lipscomb

---

https://docs.python.org/3/whatsnew/3.6.html - Edeki Okoh

Answer 1

简短的回答是“不”，长的回答是“他们努力接近这个目标”。通常，微版本遵循语义化版本控制规则；它们不应该破坏任何东西或添加功能，只是修复错误。这并不总是正确的（例如3.5.1在namedtuple上破坏了vars()，因为它引起的错误比破坏更严重），但对于代码（特别是Python级别的东西，而不是C扩展）跨越微边界破坏非常罕见。

小版本通常“添加功能”，但它们也会进行向后不兼容的更改，并提前发出警告。例如，{{link1：async和await在Python 3.7中变成了关键字}}, 这意味着使用它们作为变量名的代码会出错，但启用警告后，您将在3.6中看到一个DeprecationWarning。许多语法更改最初被引入为特殊的__future__模块的可选导入，文档记录了其成为默认行为的时间表。

在小版本中进行的更改都不是广泛的更改；我怀疑任何单个弃用或语法更改都没有影响到现有源代码的1％，但这确实发生了。如果您有100个第三方依赖项，并且您跳过了一个或两个小版本，则其中一个可能会被更改破坏（例如：pika在0.12之前使用async作为变量名，在Python 3.7上失败；他们发布了新版本来修复错误，但当然，从0.11及以下版本移动到0.12及更高版本以方式更改其自己的API可能会破坏您的代码）。

主要版本大致如您所预期；向后不兼容的更改是预期/允许的（尽管它们通常不会轻率地进行更改；更大的更改带来的好处更大）。

要点是，它接近语义化版本控制，但为了避免每几年就有主要版本发布，同时又不让语言因严格的兼容性限制而停滞不前，允许次要版本破坏少量现有代码，只要有警告（通常以使用弃用行为的代码实际警告、《新特性》文档中的注释以及有时使用__future__支持来简化迁移路径）。

这一切都在他们的开发周期文档中得到了官方记录（具体细节略有不同）：

为了澄清术语，Python使用“major.minor.micro”命名法来表示生产就绪的版本。因此，对于Python 3.1.2 final版本，它的主要版本是3，次要版本是1，微小版本是2。 新的"major versions"非常特殊;它们只在强烈不兼容的更改被认为是必要的时才会出现，并且事先计划非常长; 新的"minor versions"是功能版本;它们每年发布一次，从当前的开发分支中发布; 新的"micro versions"是bug修复版本;它们大约每两个月发布一次;它们是在维护分支中准备的。

- ShadowRanger

Answer 2

这里是更新至3.6文档的链接。

举个例子，如果在您的代码中使用了open(apath, 'U+')，那么在3.5中它会运行失败，在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本身的新版本，但仍然与生态系统的哲学相关。

- kojiro