代码之家  ›  专栏  ›  技术社区  ›  Ashwin Nanjappa

Python文件的常用头格式是什么?

  •  431
  • Ashwin Nanjappa  · 技术社区  · 16 年前

    在一篇关于Python编码准则的文档中,我遇到了Python源文件的以下标题格式:

    #!/usr/bin/env python
    
    """Foobar.py: Description of what foobar does."""
    
    __author__      = "Barack Obama"
    __copyright__   = "Copyright 2009, Planet Earth"
    

    这是Python世界中标题的标准格式吗? 我可以在标题中添加哪些其他字段/信息?

    4 回复  |  直到 11 年前
        1
  •  631
  •   Community Mohan Dere    6 年前

    Foobar 模块。

    docstring Peter's answer

    How do I organize my modules (source files)? (Archive)

    每个文件的第一行应该是 #!/usr/bin/env python . 这使得可以将文件作为隐式调用解释器的脚本运行,例如在CGI上下文中。

    接下来应该是带有描述的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__ 如果导入,应该是修复bug并进行改进的人。 __credits__ 不同于 __author__ __学分__ 包括报告错误修复、提出建议等但没有实际编写代码的人。

    Here 您有更多信息,请登录 __作者__ , __authors__ , __contact__ __copyright__ , __license__ , __deprecated__ __date__ __version__

        2
  •  197
  •   Jonathan Hartley Zombie    5 年前

    我强烈支持最小化文件头,我的意思是:

    • #! 行)如果这是一个可执行脚本
    • 模块文档串
    • 以标准方式分组的导入,例如:
      import os    # standard library
      import sys
    
      import requests  # 3rd party packages
    
      from mypackage import (  # local source
          mymodule,
          myothermodule,
      )
    

    即三组进口产品,中间只有一个空行。在每个组中,对导入进行排序。最后一个组“从本地源导入”可以是如图所示的绝对导入,也可以是显式相对导入。

    如果您有法律免责声明或许可信息,则会将其放入单独的文件中。它不需要感染每个源代码文件。你的版权应该是其中的一部分。人们应该能够在你的网站上找到它 LICENSE

    我不相信每个人都需要将任何其他数据放入所有源文件中。你可能有这样做的特殊要求,但根据定义,这些东西只适用于你。它们在推荐给每个人的一般标题中没有位置。

        3
  •  44
  •   aronadaal    8 年前

    上面的答案非常完整,但如果您想要快速且不干净的标题来复制粘贴,请使用以下方法:

    #!/usr/bin/env python
    # -*- coding: utf-8 -*-
    
    """Module documentation goes here
       and here
       and ...
    """
    

    为什么这是一个好的:

    • 第一行用于*nix用户。它将在用户路径中选择Python解释器,因此将自动选择用户首选的解释器。
    • 和一个非常简单的文档。它可以填充多行。

    另见: https://www.python.org/dev/peps/pep-0263/

    如果您只是在每个文件中编写一个类,那么您甚至不需要文档(它将放在类文档中)。

        4
  •  24
  •   John La Rooy    12 年前

    也看到 PEP 263 如果您使用的是非ascii字符集

    摘要

    本PEP建议引入一种语法来声明 Python源文件。然后,编码信息由 Python解析器使用给定的编码解释文件。最 源代码,使编写Unicode文本成为可能

    问题

    在Python2.1中,Unicode文本只能使用 基于拉丁语1的编码“unicode转义”。这使得 并在非拉丁1语言地区工作,如许多亚洲国家 最喜爱的编码,但绑定到“unicode转义”编码 用于Unicode文本。

    提议的解决办法

    我建议使Python源代码编码既可见又不受限制 通过使用特殊注释在每个源文件的基础上进行更改 在文件的顶部声明编码。

    在处理过程中,必须改变概念 Python源代码数据。

    如果没有其他编码,Python将默认使用ASCII作为标准编码 给出了编码提示。

    要定义源代码编码,必须有一个神奇的注释 可以作为第一个或第二个文件放置到源文件中 文件中的行,例如:

          # coding=<encoding name>
    

    或(使用流行编辑器认可的格式)

          #!/usr/bin/python
          # -*- coding: <encoding name> -*-
    

          #!/usr/bin/python
          # vim: set fileencoding=<encoding name> :
    

    推荐文章