Модуль logging: бортовой журнал программы вместо россыпи print.
⏱️ ~1 ч 30 мин·Средний·📚 6 уроков
Бытовая аналогия: бортовой журнал
У самолёта есть «чёрный ящик»: он непрерывно записывает, что происходило — чтобы после инцидента можно было восстановить картину. У серьёзной программы такую роль играет журнал (лог): программа по ходу работы записывает события — «запустилась», «обработала заказ», «не смогла открыть файл». Когда ночью на сервере что-то сломается, лог — единственный свидетель.
Почему не print
Пока вы учитесь, print() хватает. Но в настоящем проекте у print нет ответов на вопросы:
Когда это случилось? (нет времени события)
Насколько это серьёзно — просто информация или авария?
Как выключить отладочные сообщения в бою, не удаляя их из кода?
Как писать в файл, а не в консоль, которую никто не видит?
Всё это умеет встроенный модуль logging.
Пять уровней важности
Каждое сообщение имеет уровень — от «болтовни для отладки» до «всё упало»:
DEBUG — подробности для разработчика («вошли в функциюИменованный блок кода, который можно вызывать многократно. Может принимать аргументы и возвращать результат., x=5»);
INFO — обычные события («пользователь вошёл»);
WARNING — подозрительно, но работаем («диск почти полон»);
ERROR — операция не удалась («не смогли сохранить заказ»);
CRITICAL — программа не может продолжать.
Запустите и посмотрите, какие сообщения пройдут через фильтр level=logging.INFO:
▶ levels.py
Сообщение debug не напечаталось: уровень фильтра — INFO, всё, что ниже, отбрасывается. В этом главная сила логирования: отладочные записи не удаляют — их выключают, меняя одну строкуТекстовое значение в кавычках: "привет". Неизменяема. По-английски string (str). конфигурации (level=logging.DEBUG ↔ level=logging.WARNING).
Формат записи: время и место
В format можно добавить время, имя логгера и другие поля:
▶ format.py
📝Заметка
В реальном проекте лог пишут в файл: logging.basicConfig(filename="app.log", ...) — и события сохраняются между запусками. В браузерной песочнице мы направляем лог в sys.stdout, чтобы видеть его под ячейкой.
Логирование исключений
Внутри except используйте logging.exception() — она пишет сообщение уровня ERROR вместе с трейсбэком, так что в логе видно, где именно упало:
▶ log-exception.py
Заданиерешение.py
Напишите функцию safe_div(a, b): верните a / b, а при делении на ноль — залогируйте сообщение уровня ERROR (например, «деление на ноль») и верните None. Конфигурация logging и проверочный вызов уже в стартовом коде.
⚠️ Частые ошибки новичков
Ошибка 1. Ждать, что logging.debug(...) что-то напечатает «из коробки». По умолчанию уровень — WARNING: debug и info молча отбрасываются. Настройте basicConfig(level=...) в начале программы.
Ошибка 2. Вызывать basicConfig в середине программы и удивляться, что он «не сработал». Он применяется только один раз; повторный вызов игнорируется (если не передать force=True).
Ошибка 3. Логировать всё подряд уровнем ERROR. Тогда в логе невозможно отличить настоящую аварию от рядового события — уровни теряют смысл. Выбирайте уровень честно.
❓Проверь себя
Чем logging принципиально лучше print для рабочего проекта?
Какой уровень логирования используется по умолчанию, если не настроить basicConfig?
Что делает logging.exception("...") внутри блока except?
Что запомнить
Лог — «бортовой журнал» программы; в бою его читают вместо вашего лица у монитора.
Комментарии
Загрузка…
Загрузка комментариев…