파라미터로 메소드를 문서화하는 방법은 무엇입니까?


139

파이썬의 문서 문자열을 사용하여 매개 변수로 메소드를 문서화하는 방법은 무엇입니까?

편집 : PEP 257 은 다음 예제를 제공합니다.

def complex(real=0.0, imag=0.0):
    """Form a complex number.

    Keyword arguments:
    real -- the real part (default 0.0)
    imag -- the imaginary part (default 0.0)

    """
    if imag == 0.0 and real == 0.0: return complex_zero
    ...

이것은 대부분의 파이썬 개발자들이 사용하는 규칙입니까?

Keyword arguments:
<parameter name> -- Definition (default value if any)

나는 좀 더 공식적인 것을 기대하고 있었다

def complex(real=0.0, imag=0.0):
    """Form a complex number.

    @param: real The real part (default 0.0)
    @param: imag The imaginary part (default 0.0)

    """
    if imag == 0.0 and real == 0.0: return complex_zero
    ...

환경 : Python 2.7.1


1
PEP 257을 읽었습니까? python.org/dev/peps/pep-0257
NPE

1
몇 가지 '표준'이 있지만 실용적인 접근 방식과 특히 공식적인 것을 좋아한다면 스핑크스를 권장 합니다. Pycharm에 통합되어 잘 구조화 된 docstring을 생성 하는 데 어려움 이 없습니다. IMHO
jojo

답변:


86

내 경험을 바탕으로, NumPy와 문서화 문자열 규칙은 (PEP257 상위) 가장 널리 확산되어 다음 또한 다음과 같은 도구가 지원하는 규칙 스핑크스 .

한 가지 예 :

Parameters
----------
x : type
    Description of parameter `x`.

2
이것은 내가 기대했던 것에 더 가깝습니다. 불행히도, 나는 일반 PEP 257을 고르고 (자동 생성 HTML / PDF 문서를 잃어 버리는 대신) 내 자신의 규칙을 추가했습니다. 그러나 다음에이 솔루션을 선택하겠습니다. 감사.
David Andreoletti

5
제안 된 docstring을 처리하려고하면 Sphinx가 불평 SEVERE: Unexpected section title합니다. Sphinx를 더 행복하게 만드는 방법을 알고 있습니까?
Brandon Rhodes

: 스핑크스 이러한 규칙을 사용하는 방법에 대한이 링크 회담 @BrandonRhodes github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt
블라디미르 Keleshev

3
실제로 전에는 공간이 없습니다 Description. 나는 즉시 발견하고 생각했기 때문에 나는 NumPy와 문서를 확인 "왜이 잠깐 그 이상한? 공간. 세 개의 공간을 사용하는 거라고 누가?"
Zelphir Kaltstahl

6
이것은 질문이있을 때 가장 좋은 대답 일지 모르지만, 현재 (2017 년 말) 스핑크스가 승리했다고 생각합니다.
Alex L

120

docstring은 자유 형식이므로 코드를 구문 분석하여 API 문서를 생성하는 데 사용하는 내용에 따라 달라집니다.

Sphinx 마크 업에 익숙해지는 것이 좋습니다. 널리 사용되며 부분적으로 우수한 readthedocs.org 서비스로 인해 Python 프로젝트를 문서화하기위한 사실상의 표준이되었습니다 . Sphinx 문서 의 예제 를 파이썬 스 니펫으로 바꾸어 표현 하려면 :

def send_message(sender, recipient, message_body, priority=1):
   '''
   Send a message to a recipient

   :param str sender: The person sending the message
   :param str recipient: The recipient of the message
   :param str message_body: The body of the message
   :param priority: The priority of the message, can be a number 1-5
   :type priority: integer or None
   :return: the message id
   :rtype: int
   :raises ValueError: if the message_body exceeds 160 characters
   :raises TypeError: if the message_body is not a basestring
   '''

이 마크 업은 문서와 기타 문서 간의 상호 참조 를 지원합니다 . 스핑크스 문서는 (예를 들어)를 사용 :py:attr:하지만 :attr:소스 코드에서 문서화 할 때만 사용할 수 있습니다 .

당연히 API를 문서화하는 다른 도구가 있습니다. 명령 을 사용 하는 더 고전적인 Doxygen 이 있지만 Sphinx와 같은 Python 코드를 문서화하도록 특별히 설계되지 않았습니다.\param

여기에 비슷한 대답 이있는 비슷한 질문 이 있습니다.


9
이것은 기본적으로 PyCharm의 주석 자동 생성에 사용되는 스타일
요시야 Yoder 보낸

재료 목록과 같은 복합 유형의 구문은 어떻습니까?
matanster

그런 다음 list입니다.
anarcat

33

컨벤션 :

도구 :


업데이트 : Python 3.5부터 소형의 기계 판독 가능한 구문 인 유형 힌트 를 사용할 수 있습니다 .

from typing import Dict, Union

def foo(i: int, d: Dict[str, Union[str, int]]) -> int:
    """
    Explanation: this function takes two arguments: `i` and `d`.
    `i` is annotated simply as `int`. `d` is a dictionary with `str` keys
    and values that can be either `str` or `int`.

    The return type is `int`.

    """

이 구문의 주요 장점은 언어에 의해 정의되고 모호하지 않으므로 PyCharm과 같은 도구가 쉽게 활용할 수 있다는 것입니다.


12
이 답변이 현재 가장 많이 채택되었지만, 위의 PEP 중 어느 것도 메소드의 인수 유형을 지정하는 규칙을 제공하지 않습니다.
koriander

11

파이썬 doc 문자열은 자유 형식 이며 원하는 방식으로 문서화 할 수 있습니다.

예 :

def mymethod(self, foo, bars):
    """
    Does neat stuff!
    Parameters:
      foo - a foo of type FooType to bar with.
      bars - The list of bars
    """

이제 몇 가지 규칙이 있지만 파이썬은 어떤 규칙도 시행하지 않습니다. 일부 프로젝트에는 자체 규칙이 있습니다. docstring과 함께 작동하는 일부 도구는 특정 규칙을 따릅니다.



3

여기에 다른 답변이 이미 지적했듯이 주류는 아마도 스핑크스 방식으로 있기 때문에 나중에 스핑크스를 사용하여 멋진 문서를 생성 할 수 있습니다.

즉, 나는 개인적으로 때로는 인라인 주석 스타일을 사용합니다.

def complex(  # Form a complex number
        real=0.0,  # the real part (default 0.0)
        imag=0.0  # the imaginary part (default 0.0)
        ):  # Returns a complex number.
    """Form a complex number.

    I may still use the mainstream docstring notation,
    if I foresee a need to use some other tools
    to generate an HTML online doc later
    """
    if imag == 0.0 and real == 0.0:
        return complex_zero
    other_code()

여기에 또 하나의 예가 있으며, 인라인으로 문서화 된 몇 가지 작은 세부 사항이 있습니다.

def foo(  # Note that how I use the parenthesis rather than backslash "\"
          # to natually break the function definition into multiple lines.
        a_very_long_parameter_name,
            # The "inline" text does not really have to be at same line,
            # when your parameter name is very long.
            # Besides, you can use this way to have multiple lines doc too.
            # The one extra level indentation here natually matches the
            # original Python indentation style.
            #
            # This parameter represents blah blah
            # blah blah
            # blah blah
        param_b,  # Some description about parameter B.
            # Some more description about parameter B.
            # As you probably noticed, the vertical alignment of pound sign
            # is less a concern IMHO, as long as your docs are intuitively
            # readable.
        last_param,  # As a side note, you can use an optional comma for
                     # your last parameter, as you can do in multi-line list
                     # or dict declaration.
        ):  # So this ending parenthesis occupying its own line provides a
            # perfect chance to use inline doc to document the return value,
            # despite of its unhappy face appearance. :)
    pass

@ mark-horvath가 이미 다른 의견에서 지적했듯이 이점은 다음과 같습니다.

  • 가장 중요한 것은 매개 변수와 해당 문서가 항상 함께 유지되므로 다음과 같은 이점이 있습니다.
  • 타이핑이 적음 (변수 이름을 반복 할 필요 없음)
  • 변수 변경 / 제거시 손쉬운 유지 보수. 일부 매개 변수의 이름을 바꾼 후에는 고아 매개 변수 문서 단락이 없습니다.
  • 누락 된 댓글을 쉽게 찾을 수 있습니다.

이제 일부 사람들은이 스타일이 "못 생겼다"고 생각할 수도 있습니다. 그러나 "추악한"은 주관적인 단어입니다. 더 깔끔한 방법은이 스타일이 주류가 아니기 때문에 익숙하지 않아서 덜 편안 할 수 있다는 것입니다. "편안한"또한 주관적인 단어입니다. 그러나 요점은 위에서 설명한 모든 이점이 객관적이라는 것입니다. 표준 방식을 따르면 달성 할 수 없습니다.

앞으로 언젠가는 이러한 인라인 스타일을 사용할 수있는 문서 생성기 도구가있을 것입니다. 그것은 채택을 이끌 것입니다.

추신 :이 답변은 내가 맞을 때마다 인라인 주석을 사용하는 것을 선호합니다. 동일한 인라인 스타일을 사용하여 사전문서화합니다 .


1

매개 변수 유형을 문서화하는 더 나은 구조화 된 방법을 제공하는 유형 힌트 응답 ( https://stackoverflow.com/a/9195565/2418922 )을 기반으로 매개 변수의 유형 및 설명을 모두 문서화하는 구조화 된 방법이 있습니다.

def copy_net(
    infile: (str, 'The name of the file to send'),
    host: (str, 'The host to send the file to'),
    port: (int, 'The port to connect to')):

    pass

https://pypi.org/project/autocommand/ 에서 채택한 예


1
이것이 공식적인 구문입니까? 그것은 매우 유용하지만 공식 문서 / PEP에서 찾을 수 없습니다 ...
Ofri Raviv

1
PEP가 있다면 저도 알고 싶습니다.
DreamFlasher

-1

Docstring은 대화 형 환경 (예 : Python 셸)에서만 유용합니다. 대화 형으로 사용되지 않을 객체 (예 : 내부 객체, 프레임 워크 콜백)를 문서화 할 때는 일반적인 주석을 사용할 수도 있습니다. 다음은 들여 쓰기 된 주석을 각 줄에있는 항목에 매달 기 위해 사용하는 스타일입니다. 따라서 주석이 적용되는 것을 알 수 있습니다.

def Recomputate \
  (
    TheRotaryGyrator,
      # the rotary gyrator to operate on
    Computrons,
      # the computrons to perform the recomputation with
    Forthwith,
      # whether to recomputate forthwith or at one's leisure
  ) :
  # recomputates the specified rotary gyrator with
  # the desired computrons.
  ...
#end Recomputate

docstrings로는 이런 종류의 일을 할 수 없습니다.


46
아, 이거 못 생겼어
Misha Akovantsev

1
못생긴가요? 흥미로운 아이디어 ... 또한 그렇습니다.
David

2
변수에 대한 인라인 주석은 매우 합리적이며 타이핑이 적고 (변수 이름을 반복 할 필요가 없음) 변수를 변경 / 제거 할 때 유지 보수가 용이합니다 ... 누락 된 주석을 쉽게 찾을 수 있습니다. 서명 아래에 적절한 docstring과 결합하십시오. +1
Mark Horvath

그것은 문서로 작동하지 않습니다. 이와 같은 패키지에 주석을 달고 PyCharm 사용자가 패키지를 다운로드하면 문서에 액세스하지 않고 각 매개 변수가 수행하는 작업을 확인할 수 없습니다. 소프트웨어로는 생성 할 수 없습니다. 당신이 당신의 자신을 만들지 않는 한. 이것이 OP가 docstring에 그것을 지정하도록 요청하는 이유입니다. 늦어서 미안해

이것은 끔찍합니다.
마이클 월터스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.