Python 파일의 일반적인 헤더 형식은 무엇입니까?

Python 파일의 일반적인 헤더 형식은 무엇입니까?

Python 코딩 가이드라인에 관한 문서에서 Python 소스 파일에 대한 다음과 같은 헤더 형식을 발견했습니다.

#!/usr/bin/env python

"""Foobar.py: Description of what foobar does."""

__author__      = "Barack Obama"
__copyright__   = "Copyright 2009, Planet Earth"

이것이 Python 월드에서 헤더의 표준 형식입니까?머리글에 다른 어떤 필드/정보를 넣을 수 있습니까?Python gurus는 좋은 Python 소스 헤더에 대한 가이드라인을 공유합니다:-)

에 대한 모든 메타데이터입니다.Foobar모듈.

첫 번째는docstring그것은 이미 피터의 대답에 설명되어 있다.

모듈(소스 파일)을 정리하려면 어떻게 해야 합니까?(아카이브)

각 파일의 첫 번째 행은 입니다.이를 통해 CGI 컨텍스트 등에서 인터프리터를 암묵적으로 호출하는 스크립트로 파일을 실행할 수 있습니다.

다음은 설명이 포함된 docstring입니다.설명이 긴 경우 첫 번째 행은 다른 행과 새 행으로 구분하여 그 자체로 의미가 있는 짧은 요약이어야 합니다.

Import 문을 포함한 모든 코드는 docstring 뒤에 와야 합니다.그렇지 않으면 docstring이 인터프리터에 의해 인식되지 않고 대화형 세션(즉, ~)에서 docstring에 액세스할 수 없게 됩니다.obj.__doc__또는 자동 툴을 사용하여 문서를 생성할 때 사용합니다.

내장 모듈을 먼저 Import하고 다음으로 서드파티 모듈을 Import한 후 경로 및 자체 모듈을 변경합니다.특히 모듈의 경로와 이름은 빠르게 변경될 수 있습니다. 모듈을 한 곳에 보관하면 모듈을 쉽게 찾을 수 있습니다.

다음은 저자 정보입니다.이 정보는 다음 형식을 따라야 합니다.

__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__버그를 수정하고, Import 했을 경우는 개선해 주는 사람이어야 합니다. __credits__다르다__author__그런 점에서__credits__에는 버그 수정이나 제안 등을 보고했지만 실제로 코드를 작성하지는 않은 사람이 포함됩니다.

여기에 상세정보가 있습니다.__author__,__authors__,__contact__,__copyright__,__license__,__deprecated__,__date__그리고.__version__인식된 메타데이터로.

저는 최소한의 파일 헤더를 매우 선호합니다.즉, 다음과 같습니다.

• 해시방(#!line) 실행 가능한 스크립트인 경우
• 모듈 문서 문자열
• 표준 방식으로 그룹화된 가져오기:

  import os    # standard library
  import sys

  import requests  # 3rd party packages

  from mypackage import (  # local source
      mymodule,
      myothermodule,
  )

즉, 세 개의 수입품 그룹 사이에 하나의 공백 줄이 있는 경우.각 그룹 내에서 가져오기가 정렬됩니다.마지막 그룹(로컬 소스로부터의 Import)은 그림과 같이 절대 Import 또는 명시적인 상대 Import 중 하나입니다.

그 외의 모든 것은 시간과 시각적인 공간 낭비일 뿐 아니라 오해를 불러일으키기도 합니다.

법적 면책사항 또는 라이센스 정보가 있는 경우 별도의 파일에 저장됩니다.모든 소스 코드 파일을 감염시킬 필요는 없습니다.당신의 저작권은 여기에 포함되어야 합니다.이 ' 낫다'에서 수 거예요.LICENSE일,,, 랜랜랜코코코코 다다다다다다다

작성자 및 날짜와 같은 메타데이터는 소스 컨트롤에 의해 이미 유지되고 있습니다.파일 자체에 같은 정보의 상세, 오류, 오래된 버전을 추가할 필요가 없습니다.

모든 사람이 모든 소스 파일에 넣어야 하는 다른 데이터는 없다고 생각합니다.그렇게 해야 할 특별한 요건이 있을 수 있지만, 그러한 요건은 정의상 당신에게만 적용됩니다."모두에게 권장되는 일반 머리글"에는 해당 머리글이 없습니다.

위의 답변은 완전하지만 복사하여 붙여넣을 헤더를 더티하게 하려면 다음을 사용하십시오.

#!/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/

각 파일에 클래스를 작성하기만 하면 문서도 필요 없습니다(클래스 문서 안에 들어갑니다).

ASCII 이외의 문자 세트를 사용하고 있는 경우는, 「PE 263」도 참조해 주세요.

추상적인

이 PEP는 Python 소스 파일의 인코딩을 선언하는 구문을 도입할 것을 제안합니다.그런 다음 Python 파서가 인코딩 정보를 사용하여 지정된 인코딩을 사용하여 파일을 해석합니다.가장 주목할 만한 점은 소스 코드의 유니코드 리터럴 해석을 강화하고 유니코드 인식 편집기에서 UTF-8과 같은 유니코드 리터럴을 직접 쓸 수 있도록 한다는 것입니다.

문제

Python 2.1에서는 Unicode 리터럴은 Latin-1 기반 인코딩 "unicode-escape"를 통해서만 쓸 수 있습니다.이로 인해 많은 아시아 국가 등 라틴어 1이 아닌 지역에 거주하며 일하는 Python 사용자에게 프로그래밍 환경은 다소 비우호적입니다.프로그래머는 즐겨찾는 인코딩을 사용하여 8비트 문자열을 작성할 수 있지만 유니코드 리터럴의 경우 "유니코드 이스케이프" 인코딩에 구속됩니다.

제안 솔루션

파일 상단에 있는 특별한 코멘트를 사용하여 인코딩을 선언함으로써 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 -*-

DOC & Author 크레딧으로 여러 줄의 간단한 스트링이 좋습니다.다음은 Google Style Python Docstrings의 예제입니다.

# -*- 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: ...
        """

기타 형식

• 메타 정보 마크업| 개발 가이드

  """

        :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>
    """
  

• /common-common-common-commun-commun

        #!/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'
        # ---------------------------------------------------------------------------
  

언급URL : https://stackoverflow.com/questions/1523427/what-is-the-common-header-format-of-python-files