我应该使用哪个Python版本？
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版本的问题是值得一问的。
以下是一些简短的答案：
- 版本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（或其他一些包装库）自动安装为测试顶层模块。
- 它们可以安装并最终被其他软件包用于构建单元测试。
下图说明了标准文件层次结构的外观：
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定义的方案不兼容：首先，识别哈希值是不可订购的。
这些只是您可能遇到的第一个问题。如果您有任何其他想要我回答的问题，请随时在下面写评论。如果您有任何其他建议，您可以分享一些内容！
英文原文: https://julien.danjou.info/starting-your-first-python-project/
本文由 空心菜 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Aug 28, 2018 at 01:50 pm