Почему python разрешает утверждения по умолчанию - PullRequest
1 голос
/ 19 марта 2020

Я немного читал об утверждениях assert в python и других языках. В частности, я прочитал об утверждении в Python, Java и C. Мое понимание может быть неверным на 100%, но следующий вопрос касается Python.

В случае Python, почему утверждения включены по умолчанию ? Почему python делает это не так, как другие языки? ** Есть ли для этого особая причина - время компиляции и интерпретация?

  • В Java утверждения по умолчанию отключены, если они явно не включены.
  • В C и C ++ программы, использующие утверждения из assert.h, не отключают их по умолчанию, но большинство файлов Makefile определяют NDEBUG для выпусков / дистрибутивов.
    • CMake по умолчанию устанавливает NDEBUG для dist
    • Многие проекты определяют собственный макрос assert вместо использования assert.h и изменяют поведение по умолчанию.

Я знаю, что мой вопрос требует немного исторического контекста, но на самом деле это тот ответ, который я ищу.

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

Если вам интересно, ниже приведены источники, которые я прочитал:

Ответы [ 2 ]

2 голосов
/ 19 марта 2020

Я предполагаю, что утверждения отключены в Java, C и C ++ по соображениям производительности. Утверждения делают код медленнее, а также могут сделать невозможной некоторую оптимизацию кода. Эти языки имеют скорость в качестве основного приоритета, поэтому имеет смысл отключить их по умолчанию.

Python, с другой стороны, скорость не имеет большого значения. Посмотрите на Python Zen :

Errors should never pass silently.
Unless explicitly silenced.

Утверждения повышают AssertionError, поэтому лучше не передавать их молча.

1 голос
/ 19 марта 2020

В случае Python, почему утверждения включены по умолчанию? Почему python делает это не так, как другие языки? ** Есть ли для этого особая причина - время компиляции и интерпретация?

Потому что, вообще говоря, нет причин не делать этого. Python не является быстрым языком, и наличие кода, который выглядит так, как будто он должен работать по умолчанию, но не является странным. Кстати, это распространяется на большее количество языков, например, в Rust есть макрос assert!, который всегда запускает , и отдельный debug_assert!, который работает только в режиме отладки.

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

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

Если вы спрашиваете, распространен ли запуск pyhton без -O, тогда да. -O сравнительно мало делает, что полезно: я не думаю, что когда-либо видел кодовую базу, использующую __DEBUG__ и в обход assert всегда чувствую себя отвратительно. И -OO в основном только негативные вещи.

Единственные случаи, которые я видел, которые обычно используют -O / -OO, это:

  • Windows упаковка, где это выглядит нечасто
  • ошибочными попытками запутывания
...