Как документировать метод с параметрами?

Как документировать методы с параметрами, используя строки документации Python?

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


person David Andreoletti    schedule 08.02.2012    source источник
comment
Вы читали PEP 257? python.org/dev/peps/pep-0257   -  person NPE    schedule 08.02.2012
comment
Существует несколько «стандартов», но с практической точки зрения, особенно если вам нравится что-то формальное, я бы порекомендовал сфинкс. Его интеграция в Pycharm позволяет безболезненно создавать хорошо структурированные строки документации. по моему мнению   -  person jojo    schedule 24.06.2014


Ответы (8)


Исходя из моего опыта, соглашения о строках документации numpy (расширенный набор PEP257) являются наиболее распространенными соблюдаемыми соглашениями, которые также поддерживаются такими инструментами, как Сфинкс.

Один пример:

Parameters
----------
x : type
    Description of parameter `x`.
person Vladimir Keleshev    schedule 08.04.2012
comment
Это ближе к тому, что я ожидал. К сожалению, я выбрал простой PEP 257 и добавил собственное соглашение (за счет потери автоматически сгенерированной документации HTML/PDF). Однако в следующий раз я выберу это решение. Спасибо. - person David Andreoletti; 11.04.2012
comment
Когда я пытаюсь обработать предложенную вами строку документации, Sphinx жалуется SEVERE: Unexpected section title — знаете ли вы какой-нибудь способ сделать Sphinx счастливее? - person Brandon Rhodes; 21.01.2014
comment
@BrandonRhodes по этой ссылке рассказывает об использовании этих соглашений со Sphinx: github. com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt - person Vladimir Keleshev; 07.05.2015
comment
На самом деле перед Description не хватает пробела. Я проверил документацию numpy, потому что сразу заметил и подумал: Подождите секунду, почему здесь три пробела? Это странно. Кому нужны три пробела? - person Zelphir Kaltstahl; 18.04.2016
comment
Возможно, это был лучший ответ в то время, когда был задан вопрос, но я думаю, что на данный момент (конец 2017 года) Sphinx вышел победителем. - person Alex L; 31.10.2017

Поскольку строки документации имеют свободную форму, это действительно зависит от того, что вы используете для анализа кода для создания документации API.

Я бы рекомендовал ознакомиться с разметкой Sphinx, так как он широко используется и становится стандартом де-факто для документирования проектов Python, отчасти из-за отличного readthedocs.org< /а> служба. Чтобы перефразировать пример из документации Sphinx как фрагмент 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 используется (например) :py:attr:, тогда как вы можете просто использовать :attr: при документировании из исходного кода.

Естественно, есть и другие инструменты для документирования API. Есть более классический Doxygen, в котором используется \param commands, но они не предназначены специально для документирования кода Python, как Sphinx.

Обратите внимание, что существует похожий вопрос с похожий ответ здесь...

person anarcat    schedule 14.11.2016
comment
Это стиль, используемый автогенерацией комментариев PyCharm по умолчанию. - person Josiah Yoder; 01.09.2017
comment
Как насчет синтаксиса составных типов, таких как списки вещей? - person matanster; 28.06.2018
comment
то это list. - person anarcat; 01.07.2018

Соглашения:

Инструменты:


Обновление: начиная с 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, могут легко использовать его преимущества.

person Jakub Roztocil    schedule 08.02.2012
comment
Хотя этот ответ в настоящее время получил наибольшее количество голосов, ни один из приведенных выше PEP не содержит соглашения для указания типов аргументов метода. - person koriander; 23.09.2013

строки документа python имеют свободную форму, вы можете документировать их любым удобным для вас способом.

Примеры:

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

Теперь есть некоторые соглашения, но python не применяет ни одно из них. Некоторые проекты имеют свои собственные условности. Некоторые инструменты для работы со строками документации также следуют определенным соглашениям.

person nosklo    schedule 08.02.2012

Если вы планируете использовать Sphinx для документирования своего кода, он способен создавать хорошо отформатированные HTML-документы для ваших параметров с их функцией «подписей». http://sphinx-doc.org/domains.html#signatures

person Kyle Mede    schedule 17.02.2014

Основное направление, как уже указывалось в других ответах, вероятно, связано с Sphinx, чтобы вы могли использовать 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()

Еще один пример здесь, с некоторыми крошечными деталями, задокументированными в строке:

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: этот ответ получен из моего собственного предпочтения использования встроенных комментариев всякий раз, когда я считаю нужным. Я использую тот же встроенный стиль для документирования словаря.

person RayLuo    schedule 19.09.2016

Основываясь на ответе с подсказками типа (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/

person DreamFlasher    schedule 14.01.2020
comment
Это официальный синтаксис? Это очень полезно, однако я не могу найти его в официальных документах / PEP... - person Ofri Raviv; 08.03.2020
comment
Я бы тоже хотел это знать, есть ли для этого PEP. - person DreamFlasher; 09.03.2020

Строки документации полезны только в интерактивных средах, например. оболочка 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

Вы не можете делать такие вещи со строками документации.

person Lawrence D'Oliveiro    schedule 09.02.2012
comment
Некрасиво да? Интересная идея... тоже да. - person David; 13.11.2014
comment
Встроенные комментарии для переменных очень разумны, меньше печатать (нет необходимости повторять имя переменной), проще обслуживание при изменении/удалении переменной... легче найти отсутствующий комментарий. Объединил бы это с соответствующей строкой документации под подписью. +1 - person Mark Horvath; 24.04.2015
comment
Это не работает как документация. Если вы прокомментируете свой пакет таким образом, и пользователь PyCharm загрузит его, он не сможет проверить, что делает каждый параметр, не обращаясь к вашей документации, которую вы не сможете создать с помощью какого-либо программного обеспечения. Если только вы не сделаете свой собственный. Вот почему ОП просит указать это в строке документации. Извините так поздно. - person ; 10.04.2018
comment
Это просто ужасно. - person Michael Walters; 25.05.2018