Что такое функциональные различия между DEBUG = True и False в Django?

Каковы функциональные различия между переключением параметра DEBUG в файле settings.py приложения Django?

Сначала я предположил, что DEBUG=True просто включил возможность ведения журнала Django и промежуточное ПО для отчетов об ошибках, но теперь Я понимаю, что это было наивно для меня. Понимание того, как внутренние системы Django работают по-разному под двумя логическими настройками, помогает формировать гипотезы при работе с трудными для отладки, обычными ошибками состояния

Ответ 1

Одно из главных преимуществ DEBUG = True - подробные страницы ошибок. Django предоставляет подробную информацию о том, что пошло не так. Что очень полезно при отладке. В принципе, в режиме DEBUG django запоминает каждый SQL-запрос, который он выполняет (что опять-таки делает его полностью непригодным для производства).

Кроме того, если DEBUG = True, проверка хоста отключена. Другими словами, если DEBUG = False, необходимо установить ALLOWED_HOSTS.

Ответ 2

Начиная с Django 1.6.2 перед было указано, что ошибки импорта не обязательно попадают в DEBUG=True, но, безусловно, находятся в DEBUG=False

Простой пример: попробуйте импортировать приложение settings.py (import yourapp.settings) в одно из ваших представлений, а затем попробуйте ссылаться на несуществующую переменную: settings.var_that_does_not_exist. Это будет только проблема (вызывающая ошибки состояния 500), когда DEBUG=False для любых представлений, ссылающихся на несуществующую переменную.