Практический курс по стандартной библиотеке: https://stepik.org/course/259466/
Телеграм-канал: https://t.me/python_selfedu
The Python Standard Library: https://docs.python.org/3/library/index.html
Оглавление (2 сегментов)
Segment 1 (00:00 - 05:00)
Здравствуйте, дорогие друзья. Я Сергей Балакерев, и начиная с этого занятия, мы с вами будем изучать работу модуля Логин. Каждый, кто сталкивался из вас с разработкой проектов большой или даже средней сложности, знает, как важно вести протокол всех значимых событий, происходящих в программе. Это может быть простая регистрация нового пользователя или авторизация существующего или предупреждение о выполнении какой-либо критической операции. И, разумеется, записи о возникающих ошибках на разных уровнях иерархии. В программировании ведение такого протокола часто называется логированием, а выходные результаты с наборами конкретных записей, логами - это довольно распространённый подход при проектировании любых значимых проектов. Поэтому неудивительно, что в стандартной библиотеке языка Python существует модульный логин, позволяющий довольно просто и гибко формировать логи записями различных уровней важности. Конечно, логирование имеет смысл для более-менее серьёзных проектов, как правило, состоящих из множества программных модулей, файлов. Если вы пишете небольшую программу в несколько десятков строк, то вспомогательную информацию достаточно вводить, например, с помощью функции print или помещать файл. Но в больших проектах, над которыми обычно работает группа разработчиков, вывод и хранение различной служебной информации лучше централизовать и стандартизировать. И, кроме того, иметь возможность гибкой настройки механизма логирования. Например, легко менять формат вывода сообщений, задавать ограничения на типы выводимой информации, указывать различные источники вывода сообщений и многое другое. Как раз всё это обеспечивает мологин, который нередко применяется в реальных проектах. И мы с вами сейчас сделаем первый шаг в понимании общих принципов его работы. Когда в какой-либо программе выполняется импорт вот этого вот модуля логин, то автоматически создаётся так называемый корневой логер в виде объекта класса root loger. И этот логер един во всех модулях запускаемой программы. С помощью этого логера в дальнейшем может генерировать различные сообщения, которые являются объектами класса Lock Record. И каждое сообщение имеет три важных свойства. Это уровень важности сообщения, источник сообщения и непосредственно текст сообщения. Причём вот это вот уровень важности, он определяется целым числом от нуля до 50. И по умолчанию модуло определены следующие уровни. Уровень not - это числовое значение ноль, то есть это обработка всех типов сообщений без ограничений. Потом deb - это числовое значение 10. То есть это несколько более важное сообщение. Это сообщение уровня диагностики отладки. Потом - это информационные сообщения, числовое значение 20. Н - это предупреждение, то есть не критические, но тем не менее некие предупреждения в ходе работы программы. Это число 30. Далее error - это уже ошибки, программные ошибки. Значит, это числовое значение 40- это более важное сообщение. Ну и, наконец, critical- это критические ошибки, которые необходимо быстро исправлять. То есть вот такие вот уровни важности существуют у каждого объекты сообщений. А сами вот эти вот объекты генерируются в логере с помощью вот таких вот функций и соответствующих методов. Например, функция debug. Она формирует объект сообщения с уровнем debug info, соответственно, с уровнем inf и так далее. После этого созданный в логере объект сообщения существует исключительно в память устройства и нигде пока не отображается, чтобы пользователь мог его прочитать и проанализировать. Этот функционал целиком берут на себя так называемые хендлеры обработчики. И корневой логер по умолчанию имеет один такой хендллер, который связан со стандартным потоком ошибок и, соответственно, отображает сообщение в заданном формате. Однако часто вместо предопределённого хендлера, корневого лодера, создают свои собственные, которые могут вводить сообщения в самые разные потоки данных, например, в консоль, файл, передавать по электронной почте, отправлять по сети и так далее. В результате один логер может иметь сразу несколько хендлеров для разных типов выходных информационных потоков. Соответственно, объект сообщений, присутствующий в логере, передаётся каждому хендлеру для его обработки, например, отображение в консоли, записи в файл, передачи по сети и так далее. То есть одно сообщение может быть продублировано в разных информационных потоках. Однако часто дублировать всё подряд нет необходимости. И, например, файл может помещать записи только уровня вордены выше. PML отправлять ошибки Error или critical и так далее. Чтобы осуществить такую простую фильтрацию записей, каждый хендлер имеет заданный уровень важности обрабатываемых объектов сообщения. Например, если для handх handler консоли определить уровень инфо, то он будет в
Segment 2 (05:00 - 09:00)
консоли отображать все сообщения, которые имеют вот этот тот уровень, и, соответственно, выше более высокие числовые значения. Также у файлового хендложаража, например, мы можем определить уровень Worden. Соответственно, он будет отображать файли только сообщения от Worden и более значимые. Ну а по электронной почте отправлять сообщение error или critical. И такой уровень важности сообщения можно прописывать для любого хендлера. По умолчанию у созданного обработчика уровень важности сообщений установлен как notset, то есть ноль. И он, соответственно, обрабатывает всё, что поступает на его вход. А вот корневой логер сам по себе имеет уровень важности определённо как орден. На что это влияет? Смотрите, если в таком логере попытаться сгенерировать сообщение уровня ниже, чем орден, например, info, то объект сообщения просто не будет создан. Соответственно, никаких действий по его логированию мы не увидим, даже если хендлеры такого логера будут пропускать сообщение данного уровня. То есть на уровне самого логера можно также выполнять фильтрацию записей, задавая требуемый уровень важести для её генерации и обработки. Если же требуется ещё более тонкая фильтрация объектов сообщений, то модуль содержит специальный класс, который называется фильтр, в котором можно реализовывать дополнительную логику отбора одних записей и игнорирования остальных. Затем такой объект класса фильтра можно назначить как самому логеру, так и отдельным его хендллерам. Давайте теперь предположим, что некоторый объект сообщения дошёл до хендллеров и обрабатывается ими. И здесь стоит вопрос о формате отображаемой информации, потому что в каждом информационном потоке данные часто имеют свой собственный отображаемый формат. Для этого в модулеги существует класс форматор, с помощью которого можно определять формат отображаемой информации. И, соответственно, этот формат, то есть объект класс форматор, зачать тому или иному хендллеру. В результате каждый хендлер будет выдавать данные в требуемом пользователю виде. Вот это общий принцип работы одного корневого логера. Однако часто в реальных проектах определяется несколько логеров, например, по одному в каждом программном модуле. При этом новые созданные логеры будут связаны с корневым в виде его потомков. Мало того, каждый новый логер может иметь свой собственный набор дочерних логеров, образуя таким образом иерархическую сеть. Конечно, увлекаться созданием глубокой иерархии не стоит, потому что это скорее затрудняет анализ ошибках в логах, чем помогает этому процессу. Часто в реальных проектах добавляют по одному логеру в каждый значимый программный модуль этим ограничиваются. Реже дополнительно создают логеры для отдельных классов. Более глубокая иерархия часто только усложняет процесс анализа логов. Давайте теперь посмотрим на общий принцип работы такой иерархической системы логирования. Предположим, что один из логеров с самого нижнего уровня сгенерировал сообщение. Это сообщение отправляет всем хендлерам текущего лодера, если они у него есть. Далее, вне зависимости от того, были или не было хендлеров у логера, объект сообщения передаётся родительскому лодеру. Если оно не отфильтровывается его хендлорами, то, соответственно, обрабатывается. Итак, пока вот это сообщение не дойдёт до корневого логера. При этом оно будет отображаться всеми хендлерами на всех уровнях, в которые он попадёт. Вот общий принцип встроенной системы логирования модуля логин стандартной библиотеки дополнительно имеет встроенную возможность гибкого конфигурирования механизма логирования с использованием внешних конфигурационных файлов. Эти файлы могут содержать настройки в таких известных форматах, как Jon или Yam. Благодаря разделению настроек и самой программы появляется возможность менять поведение системы логирования, не внося изменения в программный код. Это бывает полезно, когда протестированный проект переводится в боевой режим и в логи не следует помещать отладочную информацию. На последующих занятиях мы с вами будем подробно знакомиться с реализацией этой системы логирования непосредственно на языке Python. เฮ
