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定义的方案不兼容:首先,识别哈希值是不可订购的。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180831G0AGEY00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券