У меня другое мнение относительно моего использования утверждения Python, и я хотел бы, чтобы вы сказали мне, почему я не прав - PullRequest
Новая
       23

У меня другое мнение относительно моего использования утверждения Python, и я хотел бы, чтобы вы сказали мне, почему я не прав

0 голосов
/ 26 марта 2020

Пожалуйста, выслушай меня. Я знаю, как работает assert.

Для контекста, некоторые приложения и способы использования, которые я имею в виду, включают математическую оптимизацию через GUI, поэтому функции можно вызывать сотни миллионов раз.

Оператор assert отключен в оптимизированном режиме (-O), поэтому считается плохой практикой (читай: capital sin ) полагаться на него, по мнению большинства людей (может быть, это более чем мнение, я не знаю).

Скажем, у меня есть следующая функция, которая вычисляет площадь круга: 

def area_circle(r):
    return 3.141592654 * (r**2)

Да, я знаю, нет строк документации. Это игрушечный пример. Чтобы убедиться, что radius является либо int, либо float, я бы сделал следующее: 

def area_circle(r):
    assert isinstance(r, (int, float), 'TypeError: Expected int or float, not ' + type(r).__name__
    return 3.141592654 * (r**2)

Возможно, мое мнение должно быть публично исполнено, потому что я вижу это как удобная функция, которая позволяет мне выполнять некоторую проверку ввода и тому подобное во время разработки, но затем, когда я достигаю состояния готовности к работе, я могу просто отключить эти ненужные части кода в оптимизированном режиме. Если мои системные тесты охватывают рабочие процессы, которые приводят к использованию area_circle, то я лично не хочу видеть raise операторов, потому что они просто бесполезны.

Так, как я могу сделать интегрированный системное тестирование таким образом, чтобы не замедлять работу приложения без использования assert?

РЕДАКТИРОВАТЬ 1

Вот две дополнительные части информации, которые необходимо учитывать:

  1. Внешних источников данных нет, все поступает из GUI;
  2. Проверка ввода выполняется непосредственно в GUI

1 Ответ

0 голосов
/ 26 марта 2020

Ваш тезис выглядит так: assert операторы отлично подходят для отладки (что они и есть), и что вы в ваш вариант использования могут в достаточной мере протестировать каждый путь кода, который Вы можете уверенно отключить их во время производства, чтобы повысить производительность, и что теперь вы сомневаетесь в каждом возможном использовании явных raise операторов.

Ну, не каждый код может быть проверен до такой степени. Существует код «на переднем крае», который должен выполнять проверку ввода во время выполнения , и который должен использовать явные проверки и явные операторы raise. Здорово, что у вас есть случай, когда вашему бэкэнд-коду не нужно беспокоиться о проверке ввода, потому что вы достаточно уверены, что это обрабатывается на предыдущем уровне. В таких случаях, во что бы то ни стало, не выполняйте проверку ввода и не отключайте ваши операторы assert. Это не значит, что это возможно в каждом случае. Например, вашему внешнему интерфейсу все еще потребуются явные проверки во время выполнения, и, возможно, они явно raise внутренне содержат ошибки.

raise операторы предназначены для случаев, когда ваша программа встречает исключительную ситуацию , которую она не может иметь дело с. Ваш код отправляет HTTP-запрос на удаленный сервер, который отвечает 500 Internal Error. Это исключительная ситуация . Это не счастливый путь для вашего кода. Это ситуация, с которой ваш код не может справиться, и это может произойти только во время выполнения, нет способа предотвратить это с помощью модульного тестирования. В этом случае raise исключение очень разумно.

...