问题:Python文件的常见标头格式是什么?
在有关Python编码准则的文档中,我遇到了以下Python源文件的头格式:
#!/usr/bin/env python
"""Foobar.py: Description of what foobar does."""
__author__ = "Barack Obama"
__copyright__ = "Copyright 2009, Planet Earth"
这是Python世界中标头的标准格式吗?我还可以在标题中添加哪些其他字段/信息?Python专家分享了有关好的Python源标头的指南:-)
回答 0
它是Foobar
模块的所有元数据。
第一个是docstring
模块的,已经在Peter的答案中进行了解释。
如何组织模块(源文件)?(存档)
每个文件的第一行应为
#!/usr/bin/env python
。这样就可以将文件作为脚本运行,例如在CGI上下文中隐式调用解释器。接下来应该是带有说明的文档字符串。如果描述很长,那么第一行应该是一个简短的摘要,该摘要应具有其自身的意义,并以换行符分隔其余部分。
所有代码(包括import语句)都应遵循docstring。否则,解释器将无法识别该文档字符串,并且您将无法在交互式会话中访问该文档字符串(例如,通过
obj.__doc__
)或使用自动化工具生成文档时。首先导入内置模块,然后导入第三方模块,然后再导入路径和您自己的模块。特别是,模块的路径和名称的添加可能会快速更改:将它们放在一个位置可以使它们更容易找到。
接下来应该是作者信息。此信息应遵循以下格式:
__author__ = "Rob Knight, Gavin Huttley, and Peter Maxwell" __copyright__ = "Copyright 2007, The Cogent Project" __credits__ = ["Rob Knight", "Peter Maxwell", "Gavin Huttley", "Matthew Wakefield"] __license__ = "GPL" __version__ = "1.0.1" __maintainer__ = "Rob Knight" __email__ = "rob@spot.colorado.edu" __status__ = "Production"
状态通常应为“原型”,“开发”或“生产”之一。
__maintainer__
应该是将修复错误并进行改进(如果导入)的人。__credits__
不同之处在于__author__
,这些__credits__
人报告了错误修复,提出了建议等,但实际上并未编写代码。
在这里你有更多的信息,上市__author__
,__authors__
,__contact__
,__copyright__
,__license__
,__deprecated__
,__date__
和__version__
作为公认的元数据。
回答 1
我强烈赞成使用最少的文件头,我的意思是:
#!
如果是可执行脚本,则使用hashbang(行)- 模块文档字符串
- 导入,以标准方式分组,例如:
import os # standard library
import sys
import requests # 3rd party packages
import mypackage.mymodule # local source
import mypackage.myothermodule
即。三组进口,它们之间有一个空白行。在每个组中,对进口进行排序。最后一组,从本地来源进口,可以是如图所示的绝对进口,也可以是明确的相对进口。
其他所有内容都浪费时间,占用视觉空间,并且会产生误导。
如果您有法律免责声明或许可信息,它将进入一个单独的文件中。它不需要感染每个源代码文件。您的版权应该是其中的一部分。人们应该可以在您的网站上找到它LICENSE
文件中,而不是随机的源代码。
源代码控件已经维护了诸如作者身份和日期之类的元数据。无需在文件本身中添加更详细,错误且过时的相同信息版本。
我不认为每个人都需要将任何其他数据放入其所有源文件中。您可能有这样做的特定要求,但是根据定义,这种情况仅适用于您。它们在“为所有人推荐的通用标题”中没有位置。
回答 2
上面的答案确实很完整,但是如果您想要一个快速且脏的标题来复制粘贴,请使用以下命令:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""Module documentation goes here
and here
and ...
"""
为什么这是一个好人:
- 第一行适用于* nix用户。它将在用户路径中选择Python解释器,因此将自动选择用户首选的解释器。
- 第二个是文件编码。如今,每个文件都必须具有关联的编码。UTF-8可以在任何地方使用。只是遗留项目会使用其他编码。
- 和一个非常简单的文档。它可以填充多行。
也可以看看: https //www.python.org/dev/peps/pep-0263/
如果仅在每个文件中编写一个类,则甚至不需要文档(它会放在类doc中)。
回答 3
如果使用的是非ASCII字符集,另请参阅PEP 263
抽象
该PEP建议引入一种语法,以声明Python源文件的编码。然后,Python解析器将使用编码信息使用给定的编码来解释文件。最值得注意的是,这增强了源代码中Unicode文字的解释,并使得可以在例如Unicode的编辑器中直接使用UTF-8编写Unicode文字。
问题
在Python 2.1中,只能使用基于Latin-1的编码“ unicode-escape”编写Unicode文字。这使得编程环境对在许多亚洲国家这样的非拉丁1语言环境中生活和工作的Python用户而言相当不利。程序员可以使用最喜欢的编码来编写其8位字符串,但是绑定到Unicode文字的“ unicode-escape”编码。
拟议的解决方案
我建议通过在文件顶部使用特殊注释来声明编码,从而使每个源文件都可以看到和更改Python源代码。
为了使Python知道此编码声明,在处理Python源代码数据方面需要进行一些概念上的更改。
定义编码
如果未提供其他编码提示,Python将默认使用ASCII作为标准编码。
要定义源代码编码,必须将魔术注释作为源文件的第一行或第二行放置在源文件中,例如:
# coding=<encoding name>
或(使用流行的编辑器认可的格式)
#!/usr/bin/python # -*- coding: <encoding name> -*-
要么
#!/usr/bin/python # vim: set fileencoding=<encoding name> :
…