Python版本的选择和项目目录规范

我应该使用哪个Python版本？

Python同时支持多个版本，这已不是什么秘密。解释器的每个次要版本都获得18个月的错误修复支持和5年的安全支持。例如，2018年6月27日发布的Python 3.7将在2019年10月（15个月后）发布Python 3.8之前得到支持。在2019年12月左右，将发生Python 3.7的最后一个错误修复版本，并且每个人都应该切换到Python 3.8。

这一点很重要，因为解释器的版本将完全是软件生命周期的一部分。最重要的是，我们应该考虑与的问题。对于使用(非常)旧平台的人来说，这仍然是一个开放而没有解决的问题。

最后，一个人应该使用哪种Python版本的问题是值得一问的。

以下是一些简短的答案：

版本2.6及更早版本现在已经过时了，因此您根本不必担心支持它们。如果您打算支持这些旧版本，请注意，您将更难确保您的程序也支持Python 3.x. 虽然您可能仍会在某些旧系统上遇到Python 2.6; 如果是这样的话，抱歉！

2.7版本仍然是Python 2.x的最后一个版本。我不认为现在有一种系统不能以某种方式提供Python 3。所以除非你再次进行考古学，否则就算了。2020年之后将不再支持Python 2.7，所以你要做的最后一件事就是建立一个基于它的新软件。

版本3.7是撰写本文时Python 3分支的最新版本，这是您应该定位的版本。最新的操作系统至少运行3.6，因此在您定位这些操作系统的情况下，您可以确保您的应用程序也可以使用3.7。

项目布局

开始一个新项目总是一个难题。你永远不知道如何组织你的文件。但是，一旦你对那里的最佳实践有了正确的理解，它就非常简单了。

首先，您的项目结构应该是相当基础的。明智地使用包和层次结构：深层次结构可能是导航的噩梦，而平面层次结构往往变得臃肿。

然后，避免犯一些常见的错误。不要将单元测试留在包目录之外。这些测试应包含在您的软件的子包中，以便：

它们不会被setuptools（或其他一些包装库）自动安装为测试顶层模块。

它们可以安装并最终被其他软件包用于构建单元测试。

下图说明了标准文件层次结构的外观：

是Python安装脚本及其配套设置的标准名称以及其附带程序，它应包含安装脚本配置。运行时，setup.py使用Python分发实用程序安装程序包。

您还可以向用户提供有价值的信息（或者README.txt，或者任何适合您的文件名）。最后，该docs目录应包含reStructuredText格式的包文档，该文档将由Sphinx使用。

包通常必须提供额外的数据，例如图像，shell脚本等。不幸的是，没有普遍接受的标准来存储这些文件的位置。只需将它们放在对项目最有意义的地方：根据其功能，例如，Web应用程序模板可以templates放在程序包根目录的目录中。

还经常出现以下顶级目录：

用于示例配置文件。

用于shell脚本或相关工具。

对于您编写的将要安装的二进制脚本setup.py。

我经常遇到另一个设计问题。在创建文件或模块时，一些开发人员会根据他们将存储的代码类型创建它们。例如，他们会创建或文件。这是一种可怕的方法。在导航代码时，它对任何开发人员都没有帮助。代码组织没有从中受益，它迫使读者无缘无故地在文件之间跳转。在某些情况下，存在一些例外，例如库，因为它们确实为消费者公开了完整的API。但是，除此之外，在您的应用程序中执行此操作之前请三思而后行。

根据功能组织代码，而不是基于类型。

创建一个只包含文件的模块目录也是一个坏主意。例如，不要创建一个新的目录hooks名为一个文件在它放在hooks.py就足够了吧。如果创建目录，它应该包含属于该目录所代表类别的其他几个Python文件。

还要非常小心你放在文件中的代码：它将在第一次加载目录中包含的任何模块时被调用和执行。这可能会产生不必要的副作用。除非你知道你在做什么，否则这些文件大部分时间都应该是空的。

版本编号

需要标记软件版本以了解哪一个比另一个更新。随着每一段代码的发展，每个项目都需要能够组织其时间表。

组织版本号的方法有很多种，但PEP 440引入了一种版本格式，每个Python软件包，理想情况下每个应用程序都应遵循这种格式。这样，程序和包将能够快速可靠地识别它们所需的软件包版本。

PEP 440为版本编号定义以下正则表达式格式：

N[.N]+[N][.postN][.devN]

这允许标准编号像或。

但请注意：

相当于; 等同于等等。

版本匹配被视为最终版本。

基于日期的版本被视为无效。用于检测格式版本号的自动化工具如果检测到大于或等于的版本号，将会（或应该）引发错误。

最终组件也可以使用以下格式：

（例如）表示alpha版本，可能不稳定且缺少功能的版本。

（例如）表示测试版，可能是功能完整但仍有错误的版本。

或（例如）表示（release）候选人，可能作为最终产品发布的版本，除非出现重大错误。虽然和后缀具有相同的含义，但如果两者都使用，则发布版本被认为比版本更新。

这些后缀也可以使用：

（例如）表示发布后。这些通常用于解决发布过程中的小错误（例如发行说明中的错误）。在发布修正版本时不应该使用; 相反，您应该增加次要版本号。

（例如）表示发展版本。不鼓励使用此后缀，因为人类难以解析。它表示它符合条件的版本的预发行版：例如，在任何alpha，beta，候选版本或最终版本之前指示版本的第三个开发版本。

对于大多数常见用例，此方案应该足够了。

您可能听说过语义版本控制，它提供了自己的版本编号指南。该规范与PEP 440部分重叠，但不幸的是，它们并不完全兼容。例如，Semantic Versioning对预发布版本控制的建议使用的方案不符合PEP 440。

许多DVCS平台（例如Git和Mercurial）可以使用标识哈希生成版本号（对于Git，请参阅）。不幸的是，这个系统与PEP 440定义的方案不兼容：首先，识别哈希值是不可订购的。