パラメータを使用してメソッドを文書化する方法は?


139

Pythonのドキュメント文字列を使用して、パラメーターを含むメソッドをドキュメント化する方法は?

編集: 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
    ...

これはほとんどのPython開発者が使用する規則ですか?

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 docstring規約(PEP257スーパーセット)は、Sphinxなどのツールでもサポートされている、最も広く普及している規約です。

一例:

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

2
これは私が期待したものに近いです。残念ながら、私は単純なPEP 257を選び、独自の規則を追加しました(自動生成されたHTML / PDFドキュメントを失うことを犠牲にして)。ただし、次回は、このソリューションを選択します。ありがとう。
David Andreoletti、2012

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。私はすぐに気付いて「ちょっと待って、なぜ3つのスペースなのか?それは奇妙です。誰が3つのスペースを使うのですか?」
Zelphir Kaltstahl 16

6
これは、質問された時点で最良の回答だったかもしれませんが、現時点(2017年後半)で、Sphinxが勝利を収めたと思います。
Alex L

120

docstringは自由形式であるため、コードを解析してAPIドキュメントを生成するために何を使用するかによって異なります。

私は精通取得をお勧めしSphinxのマークアップ、それが広く使用されているため、そして優れることの一部に、Pythonのプロジェクトを文書化するためのデファクトスタンダードになりつつありreadthedocs.orgサービス。するために、例を言い換え Pythonのスニペットとしてスフィンクスのドキュメントから:

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
   '''

このマークアップは、ドキュメント間のクロスリファレンスなどをサポートします。Sphinxのドキュメントでは(eg)を:py:attr:使用:attr:していますが、ソースコードからドキュメント化する場合はそのまま使用できます。

もちろん、APIを文書化する他のツールもあります。コマンドを使用するより古典的なDoxygenがあり\param ますが、これらはSphinxのようにPythonコードを文書化するように特別に設計されていません。

ここに同様の答えを持つ同様の質問があることに注意してください...


9
これは、デフォルトでPyCharmのコメント自動生成で使用されるスタイルです
Josiah 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はどちらも、メソッドの引数のタイプを指定するための規則を提供していません。
コリアンダー2013

11

python doc文字列は自由形式です。好きな方法でドキュメント化できます。

例:

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

現在、いくつかの規約がありますが、Pythonはそれらを強制しません。一部のプロジェクトには独自の規則があります。docstringを操作するいくつかのツールも、特定の規則に従います。



3

主流は、ここで他の回答がすでに指摘したように、おそらくスフィンクスの方法で進んでいますを使用して、Sphinxを使用してこれらの豪華なドキュメントを後で生成できるすることです。

そうは言っても、私は時々インラインコメントスタイルで行きます。

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()

ここにもう1つの例を示します。小さな詳細がインラインで文書化されています。

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が別のコメントですでに指摘したように)利点は次のとおりです。

  • 最も重要なのは、パラメーターとそのドキュメントが常に一緒にあることです。
  • 入力が少ない(変数名を繰り返す必要がない)
  • 変数の変更/削除時のメンテナンスが容易になります。一部のパラメーターの名前を変更した後、孤立したパラメータードキュメントの段落はありません。
  • 不足しているコメントを見つけやすくなります。

さて、このスタイルは「醜い」と思われるかもしれません。しかし、「醜い」とは主観的な言葉だと思います。より控えめな言い方をすると、このスタイルは主流ではないため、見慣れないものになり、快適さが低下する可能性があります。繰り返しになりますが、「快適」も主観的な言葉です。しかし、要点は、上記のすべての利点は客観的であるということです。標準的な方法に従えば達成できません。

うまくいけば、将来的には、そのようなインラインスタイルも使用できるドキュメントジェネレータツールが提供される予定です。それが採用を促進します。

PS:この答えは、自分が適切だと思うときはいつでもインラインコメントを使用するという私の個人的な好みに基づいています。辞書を文書化するために同じインラインスタイルを使用していますます。


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

このようなことをdocstringで行うことはできません。


46
ああ、これは醜く見えます。
Misha Akovantsev

1
醜いですか?興味深いアイデア...はい。
デビッド

2
変数のインラインコメントは非常に賢明で、入力が少なく(変数名を繰り返す必要がない)、変数の変更/削除時のメンテナンスが簡単です...欠けているコメントを見つけやすくなります。それを署名の下の適切なdocstringと組み合わせます。+1
Mark Horvath 2015

ドキュメントとしては機能しません。このようにパッケージにコメントを付け、PyCharmユーザーがパッケージをダウンロードした場合、ドキュメントにアクセスしないと各パラメーターの機能を確認できません。これは、ソフトウェアで生成することはできません。自分で作らない限り。OPがdocstringでそれを指定するように要求するのはそのためです。遅くなってすみません。

これはひどいです。
マイケルウォルターズ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.