Python同时支持多个版本,这已不是什么秘密。解释器的每个次要版本都获得18个月的错误修复支持和5年的安全支持。例如,2018年6月27日发布的Python 3.7将在2019年10月(15个月后)发布Python 3.8之前得到支持。在2019年12月左右,将发生Python 3.7的最后一个错误修复版本,并且每个人都应该切换到Python 3.8。
这一点很重要,因为解释器的版本将完全是软件生命周期的一部分。最重要的是,我们应该考虑Python2
与Python3
的问题。对于使用(非常)旧平台的人来说,这仍然是一个开放而没有解决的问题。
最后,一个人应该使用哪种Python版本的问题是值得一问的。
以下是一些简短的答案:
开始一个新项目总是一个难题。你永远不知道如何组织你的文件。但是,一旦你对那里的最佳实践有了正确的理解,它就非常简单了。
首先,您的项目结构应该是相当基础的。明智地使用包和层次结构:深层次结构可能是导航的噩梦,而平面层次结构往往变得臃肿。
然后,避免犯一些常见的错误。不要将单元测试留在包目录之外。这些测试应包含在您的软件的子包中,以便:
下图说明了标准文件层次结构的外观:
setup.py
是Python安装脚本及其配套设置的标准名称以及其附带程序setup.cfg
,它应包含安装脚本配置。运行时,setup.py使用Python分发实用程序安装程序包。
您还可以向用户提供有价值的信息README.rst
(或者README.txt,或者任何适合您的文件名)。最后,该docs目录应包含reStructuredText格式的包文档,该文档将由Sphinx使用。
包通常必须提供额外的数据,例如图像,shell脚本等。不幸的是,没有普遍接受的标准来存储这些文件的位置。只需将它们放在对项目最有意义的地方:根据其功能,例如,Web应用程序模板可以templates放在程序包根目录的目录中。
还经常出现以下顶级目录:
etc
用于示例配置文件。tools
用于shell脚本或相关工具。bin
对于您编写的将要安装的二进制脚本setup.py。我经常遇到另一个设计问题。在创建文件或模块时,一些开发人员会根据他们将存储的代码类型创建它们。例如,他们会创建functions.py
或exceptions.py
文件。这是一种可怕的方法。在导航代码时,它对任何开发人员都没有帮助。代码组织没有从中受益,它迫使读者无缘无故地在文件之间跳转。在某些情况下,存在一些例外,例如库,因为它们确实为消费者公开了完整的API。但是,除此之外,在您的应用程序中执行此操作之前请三思而后行。
根据功能组织代码,而不是基于类型。
创建一个只包含__init__.py
文件的模块目录也是一个坏主意。例如,不要创建一个新的目录hooks名为一个文件hooks/__init__.py
在它放在hooks.py就足够了吧。如果创建目录,它应该包含属于该目录所代表类别的其他几个Python文件。
还要非常小心你放在__init__.py
文件中的代码:它将在第一次加载目录中包含的任何模块时被调用和执行。这可能会产生不必要的副作用。__init__.py
除非你知道你在做什么,否则这些文件大部分时间都应该是空的。
需要标记软件版本以了解哪一个比另一个更新。随着每一段代码的发展,每个项目都需要能够组织其时间表。
组织版本号的方法有很多种,但PEP 440引入了一种版本格式,每个Python软件包,理想情况下每个应用程序都应遵循这种格式。这样,程序和包将能够快速可靠地识别它们所需的软件包版本。
PEP 440为版本编号定义以下正则表达式格式:
N[.N]+[{a|b|c|rc}N][.postN][.devN]
这允许标准编号像1.2
或1.2.3
。
但请注意:
1.2
相当于1.2.0
; 1.3.4
等同于1.3.4.0
等等。N[.N]+
被视为最终版本。2013.06.22
被视为无效。用于检测PEP 440
格式版本号的自动化工具如果检测到大于或等于的版本号,将会(或应该)引发错误1980
。最终组件也可以使用以下格式:
N[.N]+aN
(例如1.2a1
)表示alpha版本,可能不稳定且缺少功能的版本。N[.N]+bN
(例如2.3.1b2
)表示测试版,可能是功能完整但仍有错误的版本。N[.N]+cN
或N[.N]+rcN
(例如0.4rc1
)表示(release)候选人,可能作为最终产品发布的版本,除非出现重大错误。虽然rc
和c
后缀具有相同的含义,但如果两者都使用,则rc
发布版本被认为比c
版本更新。这些后缀也可以使用:
.postN
(例如1.4.post2
)表示发布后。这些通常用于解决发布过程中的小错误(例如发行说明中的错误)。.postN
在发布修正版本时不应该使用; 相反,您应该增加次要版本号。.devN
(例如2.3.4.dev3
)表示发展版本。不鼓励使用此后缀,因为人类难以解析。它表示它符合条件的版本的预发行版:例如,在任何alpha,beta,候选版本或最终版本之前2.3.4.dev3
指示版本的第三个开发版本2.3.4
。对于大多数常见用例,此方案应该足够了。
您可能听说过语义版本控制,它提供了自己的版本编号指南。该规范与PEP 440部分重叠,但不幸的是,它们并不完全兼容。例如,Semantic Versioning对预发布版本控制的建议使用的方案
1.0.0-alpha+001
不符合PEP 440。
许多DVCS平台(例如Git和Mercurial)可以使用标识哈希生成版本号(对于Git,请参阅git describe
)。不幸的是,这个系统与PEP 440定义的方案不兼容:首先,识别哈希值是不可订购的。