python - python 3 是否在语义上版本化并向前兼容

Question

我正在寻找一些希望引入 Python 3.6 以在以 3.5 为标准的环境中使用的软件。阅读 Python 的文档，我找不到任何关于是否:

3.5 代表语义版本号

3.6 代表向前兼容的升级(即:为 3.5 运行时编写的代码保证在 3.6 运行时中工作)

this page about porting to 3.7 的事实存在让我强烈认为不，但我看不到有关版本号含义的官方文档(如果有的话，ala Linux 内核版本控制)

在更一般的意义上 - 在 3.X 发布流中是否有围绕兼容性标准的 PEP？

Answer 1

简短的回答是“不”，长的回答是“他们为接近它而努力”。
通常，微版本匹配语义版本控制规则；他们不应该破坏任何东西或添加功能，只是修复错误。情况并非总是如此(例如 3.5.1 broke vars() on a namedtuple , because it caused a bug that was worse than the break when it came up )，但代码(尤其是 Python 级别的东西，与 C 扩展相反)突破微边界的情况非常罕见。
次要版本主要是“添加功能”，但它们也会在事先警告的情况下进行向后不兼容的更改。例如， async and await became keywords in Python 3.7 ，这意味着将它们用作变量名的代码损坏了，但启用了警告，you would have seen a DeprecationWarning in 3.6 .许多语法更改最初是作为从特殊 __future__ 中的可选导入引入的。模块，具有成为默认行为的记录时间表。
次要版本中所做的更改都不是广泛的更改；我怀疑任何个别的弃用或语法更改甚至影响了 1% 的现有源代码，但它确实发生了。如果您有一百个第三方依赖项，并且您正在跳过一两个次要版本，那么其中一个很可能会被更改破坏(例如:pika 之前的 0.12使用 async 作为变量名，并在 Python 3.7 上中断；他们发布了修复错误的新版本，但当然，从 0.11 及更低版本移动到 0.12 及更高版本以可能破坏的方式更改了他们自己的 API你的代码)。
主要版本大致如您所料；向后不兼容的更改是预期/允许的(尽管它们通常不会轻率地进行；更改越大， yield 越大)。
关键是，它接近语义版本控制，但为了不每隔几年发布一次主要版本，同时也不让语言由于严格的兼容性限制而停滞不前，允许次要版本破坏少量现有代码，只要存在是警告(通常以使用已弃用行为的代码的实际警告的形式，关于 What's New 文档的注释，有时 __future__ 支持以简化迁移路径)。
所有这些都在其Development Cycle documentation 中正式记录(细节略少)。 :

To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.

• new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;
• new minor versions are feature releases; they get released annually, from the current in-development branch;
• new micro versions are bugfix releases; they get released roughly every 2 months; they are prepared in maintenance branches.