5

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

  • 3.5 代表一个语义版本号
  • 3.6 将代表向前兼容的升级（即：为 3.5 运行时编写的代码保证在 3.6 运行时中工作）

这个关于移植到 3.7 的页面存在的事实让我强烈认为不，但我看不到关于版本号意味着什么的官方文档（如果有的话，ala Linux 内核版本控制）

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

4

2 回答 2

6

The short answer is "No", the long answer is "They strive for something close to it".

As a rule, micro versions match semantic versioning rules; they're not supposed to break anything or add features, just fix bugs. This isn't always the case (e.g. 3.5.1 broke vars() on a namedtuple, because it caused a bug that was worse than the break when it came up), but it's very rare for code (especially Python level stuff, as opposed to C extensions) to break across a micro boundary.

Minor versions mostly "add features", but they will also make backwards incompatible changes with prior warning. For example, async and await became keywords in Python 3.7, which meant code using them as variable names broke, but with warnings enabled, you would have seen a DeprecationWarning in 3.6. Many syntax changes are initially introduced as optional imports from the special __future__ module, with documented timelines for becoming the default behavior.

None of the changes made in minor releases are broad changes; I doubt any individual deprecation or syntax change has affected even 1% of existing source code, but it does happen. If you've got a hundred third party dependencies, and you're jumping a minor version or two, there is a non-trivial chance that one of them will be broken by the change (example: pika prior to 0.12 used async as a variable name, and broke on Python 3.7; they released new versions that fixed the bug, but of course, moving from 0.11 and lower to 0.12 and higher changed their own API in ways that might break your code).

Major versions are roughly as you'd expect; backwards incompatible changes are expected/allowed (though they're generally not made frivolously; the bigger the change, the bigger the benefit).

Point is, it's close to semantic versioning, but in the interests of not having major releases every few years, while also not letting the language stagnate due to strict compatibility constraints, minor releases are allowed to break small amounts of existing code as long as there is warning (typically in the form of actual warnings from code using deprecated behavior, notes on the What's New documentation, and sometimes __future__ support to ease the migration path).

This is all officially documented (with slightly less detail) in their 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.
于 2020-02-26T20:46:30.817 回答
3

这是关于更新到 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 本身，但仍然与生态系统的哲学相关。

于 2020-02-26T20:10:01.437 回答