我在一份关于Python编码指南的文档中看到了以下Python源文件的标题格式：
#!/usr/bin/env python
"""Foobar.py: Description of what foobar does."""
__author__ = "Barack Obama"
__copyright__ = "Copyright 2009, Planet Earth"
这是Python世界中的标准头格式吗？ 在头部还能放置哪些字段/信息呢？ Python专家们，请分享一下有关良好Python源代码头的准则 :-)
这些都是Foobar模块的元数据。
第一个元数据是该模块的docstring，其已经在Peter's answer中进行了解释。
如何组织我的模块（源文件）？ (存档)
每个文件的第一行应该是
#!/usr/bin/env python。 这样可以将该文件作为脚本隐式地调用解释器，例如在 CGI 上下文中运行。接下来应该是具有描述的docstring。 如果描述很长，则第一行应该是一个独立的简短摘要，通过换行符与其余部分分开。
包括导入语句在内的所有代码都应跟随在docstring之后。 否则，解释器将不会识别该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__不同，它包括报告 bug 修复，提出建议等但实际上没有编写代码的人。这里有更多信息，列出了被认可的元数据，如
__author__，__authors__，__contact__，__copyright__，__license__，__deprecated__，__date__和__version__。
__version__需要直接放在主文档字符串之后，并且前后需要有一个空行。同时，最佳实践是在shebang下面立即定义字符集 - # -*- coding: utf-8 -*-。 - Dave Lasley我强烈支持使用最小的文件头，也就是仅包含:
#!/usr/bin/env python # [1]
"""\
This script foos the given bars [2]
Usage: myscript.py BAR1 BAR2
"""
import os # standard library, [3]
import sys
import requests # 3rd party packages
import mypackage # local source
[1] 哈希注释只有在文件需要被直接执行，即以 myscript.py 或 myscript 或甚至 python myscript.py 运行时才需要添加。在最后一种情况下不使用哈希注释，但提供它可以给用户选择以任何一种方式执行它。如果该文件是一个模块，仅用于被其他Python文件导入，则不应包含哈希注释。[2] 模块文档字符串。[3] 导入语句按照标准的方式分组，即三组导入语句之间各有一个空行。每个组内部，导入语句应按字母顺序排序。最终一组，导入自本地源，可以是如上所示的绝对导入，也可以是显式相对导入。其他内容都是浪费时间-对作者和后续维护者都是如此。它浪费了文件顶部宝贵的可视空间，其中的信息最好在其他地方进行跟踪，并且容易变得过时并且具有误导性。
如果您有法律声明或许可信息，它应该放在单独的文件中。它不需要感染每个源代码文件。您的版权应该是其中一部分。人们应该能够在您的 LICENSE 文件中找到它，而不是在随机的源代码中。
作者和日期等元数据已经由您的源代码控制进行维护。没有必要在文件本身中添加较少详细、错误和过时版本的相同信息。
我认为没有其他数据是每个人都需要放入所有源文件的。您可能有某些特定的要求，但这些东西仅适用于您，按定义只适用于您。它们在“推荐给所有人的通用标题”中没有任何位置。
上面的回答非常详细，但如果您想快速复制粘贴一个简单的标题，可以使用以下内容：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""Module documentation goes here
and here
and ...
"""
为什么这是一个好的选择：
另请参阅：https://www.python.org/dev/peps/pep-0263/
如果您只在每个文件中编写一个类，则甚至不需要文档（它将放在类doc内）。
如果您使用非ASCII字符集，请参阅PEP 263
摘要
本PEP提议引入一种语法来声明Python源文件的编码方式。然后，Python解析器将使用给定的编码方式来解释该文件的内容。最重要的是，这增强了源代码中Unicode文字的解释，并使得可以直接在支持Unicode的编辑器中使用UTF-8等编码方式编写Unicode文字。
问题
在Python 2.1中，只能使用基于Latin-1的编码“unicode-escape”来编写Unicode文字。这使得编程环境对于许多亚洲国家的Python用户而言不太友好。程序员可以使用喜欢的编码方式编写其8位字符串，但必须使用“unicode-escape”编码方式编写Unicode文字。
解决方案建议
我建议通过在文件顶部使用特殊注释来为每个Python源文件定义编码方式，从而使Python源代码编码方式可见且可更改。
为了使Python能够感知这种编码声明，必须对处理Python源代码数据进行一些概念性的更改。
定义编码方式
如果没有给出其他编码提示，Python将默认使用ASCII作为标准编码。
要定义源代码编码方式，必须在源文件中放置一个特殊的注释，该注释应作为文件的第一行或第二行，例如：
# coding=<encoding name>或（使用流行编辑器所识别的格式）
或。#!/usr/bin/python # -*- coding: <encoding name> -*-#!/usr/bin/python # vim: set fileencoding=<encoding name> :...
在一些项目中，我在Linux机器的第一行使用以下代码：
# -*- coding: utf-8 -*-
# -*- coding: utf-8 -*-
"""Example Google style docstrings.
This module demonstrates documentation as specified by the `Google Python
Style Guide`_. Docstrings may extend over multiple lines. Sections are created
with a section header and a colon followed by a block of indented text.
Example:
Examples can be given using either the ``Example`` or ``Examples``
sections. Sections support any reStructuredText formatting, including
literal blocks::
$ python example_google.py
Section breaks are created by resuming unindented text. Section breaks
are also implicitly created anytime a new section starts.
Attributes:
module_level_variable1 (int): Module level variables may be documented in
either the ``Attributes`` section of the module docstring, or in an
inline docstring immediately following the variable.
Either form is acceptable, but the two should not be mixed. Choose
one convention to document module level variables and be consistent
with it.
Todo:
* For module TODOs
* You have to also use ``sphinx.ext.todo`` extension
.. _Google Python Style Guide:
http://google.github.io/styleguide/pyguide.html
"""
还可以添加以下内容：
"""
@Author: ...
@Date: ....
@Credit: ...
@Links: ...
"""
Meta-information markup | devguide
"""
:mod:`parrot` -- Dead parrot access
===================================
.. module:: parrot
:platform: Unix, Windows
:synopsis: Analyze and reanimate dead parrots.
.. moduleauthor:: Eric Cleese <eric@python.invalid>
.. moduleauthor:: John Idle <john@python.invalid>
"""
#!/usr/bin/env python3 Line 1
# -*- coding: utf-8 -*- Line 2
#----------------------------------------------------------------------------
# Created By : name_of_the_creator Line 3
# Created Date: date/month/time ..etc
# version ='1.0'
# ---------------------------------------------------------------------------
同其他答案一样，我也做出了相似的报告
__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"
utf-8编码，因为它是默认的。顺便说一下，这与Linux无关。 - Mikaelblomkvistsson