Это зависит от того, для кого (или кого) вы пишете докшрин. Для автоматического преобразования в документации API, мне нравится Google-style docstrings, который будет выглядеть так:
def inv(a):
"""Return the inverse of the argument.
Arguments:
a (int): The number to invert.
Returns:
float: The inverse of the argument.
Raises:
TypeError: If 1 cannot be divided by the argument.
ZeroDivisionError: If the argument is zero.
"""
return 1/a
Здесь я включил все исключения, что функция, скорее всего, поднять. Обратите внимание, что нет необходимости явно указывать raise ZeroDivisionError
- это произойдет автоматически, если вы попытаетесь делить на ноль.
Однако, если вы не создаете документацию из строку документации, я бы, вероятно, просто включить строку описания для такой простой функции:
def inv(a):
"""Return the inverse of the argument."""
return 1/a
Любое использование его, вероятно, знаете, что вы не может инвертировать, например строки.
Я не хочу, чтобы проверить типы здесь, правильно?
Я бы не стал - если пользователь, прочитав вашу документацию, решит передать, например. строка в функцию, которую они должны ожидать, чтобы получить TypeError
, и нет смысла тестировать тип аргумента, чтобы потом вызывать то же самое исключение, что код все равно поднялся бы (опять же, см. также ZeroDivisionError
!) То есть, если только например float
или complex
номера должны быть недопустимыми вводами, и в этом случае вам придется обрабатывать их вручную.
Спасибо за ответы. Я также вижу, что ваш вариант более точно соответствует принципу EAFP, чем мой. Кроме того, имя функции предполагает, что может быть вставлена матрица. Следовательно, если не указывать, что функция принимает целые аргументы (как предполагает Amath), наличие TypeError с его описанием подчеркивает цель функции лучше (на мой взгляд) – Quickbeam2k1