如果 Python 版本可能包含超过 3 个字符，那么 PEP 508 中环境标记变量“python_version”的定义是什么？

Question

我偶然发现了一个简单的问题。这不是很重要，但我对此原因很感兴趣，还没有找到快速的答案。

根据PEP 508 -- Environment Markers (section "Specification" - "Environment markers")标记变量python_version定义为platform.python_version()[:3]。

所以对于 Python 3.5.2，python_version 将是 3.5。

但是，如果主要或次要版本号高于 9 怎么办？版本号将包含 3 个以上的字符，[:3] 将对其进行裁剪。这难道不是未来 Python 版本的可能性吗？

为什么不使用类似".".join(platform.python_version().split(".", 2)[:2]) 的东西，它看起来仍然很基本，并且不会使代码过于复杂？

Answer 1

现在已更正此问题，作为此问题的后续。请参阅更新后的 PEP 中的 issue #560、pull request #1123 和 summary of changes：

• python_version 的定义从platform.python_version()[:3] 更改为'.'.join(platform.python_version_tuple()[:2]，以适应具有2 位主要和次要版本的潜在Python 未来版本（例如3.10）。 [7]

packaging库源代码has followed suit。

---

原答案

我确信这只是出于文档目的的疏忽或简化。 意图显然是提供major.minor版本字符串。

请注意，从历史上看，从来没有双位数的次要版本号。到目前为止，Python 一直只用一位数来管理。迄今为止，最高的数字是1.6、2.7 和3.7。这并不是说将来永远不会有3.10，但到目前为止，它还没有出现。

我想象一个使用platform.python_version_tuple()的实际实现：

return '.'.join(platform.python_version_tuple()[:2]

或

major, minor, patch = platform.python_version_tuple()
return '{}.{}'.format(major, minor)

但是，这两种形式都比较冗长，无法放入旨在记录而不是规定代码的 PEP 表列中。

如有疑问，请写信至 Python-dev 邮件列表。我敢肯定，如果这变得如此混乱以至于有问题，可以调整 PEP。

至于点子；它使用出售的packaging library 来处理具有implemented the python_version marker verbatim as specced in the PEP 的环境标记。如果您对此有强烈的感觉，您可以在那里提出问题，PEP 维护人员正在积极参与该项目。

请注意，还有 大量 时间。到目前为止，每个 3.x 版本大约需要 18 个月才能出现（3.2：2011-02、3.3：2012-09、3.4：2014-03、3.5：2015-09、3.6：2016-12、3.7：预计 2018- 06)，所以我们有 5 年左右的时间来解决这个问题。