Введение в logging на Python

Мы описывали концептуальные варианты поиска проблемы в коде, давали небольшой пример логирования и писали о разухабистом логировании.

Пора немного углубиться в детали логирования. Разберём модуль logging из стандартной библиотеки питона. В статье автор даёт пример лога своего проекта, подробно описывает сущность logger, после чего
– описывает уровни логирования debug-info-warning-error-critical, не забывает о методе exception, который работает как error плюс выводит информацию об исключении

– объясняет, что такое handler и разбирает некоторые варианты использования. К logger можно привязать несколько обработчиков, чтобы одновременно писать в несколько локаций. На наш взгляд, сейчас эта настройка потеряла актуальность – писать надо в стандартные потоки упакованного в докер приложения, а дальше собирать логи снаружи

– с помощью Formatter расширяет запись в логе дополнительной информацией. Вот это ключевая фича, которая отличает логирование от отладочных принтов. Для лога мы можем настройкой изменить все сообщения, добавив туда время, уровень предупреждения, строчку и файл возникновения сообщения и многое другое

– применяет Filter, чтобы перестать писать часть сообщений, или, наоборот, писать только определённые сообщения в лог. Бывает удобно, но на текущий момент чаще это решается снаружи путём поиска по логам

– применяет LoggerAdapter для внедрения дополнительной информации в лог-сообщение

– применяет extra для логирования сущностей или их частей, например, включения в лог текста запроса веб-сервера

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

– напоминает о наследовании логера, что позволяет упростить настройку логирования в модулях, указывая только индивидуальные настройки – общая часть будет взята из класса-родителя

В конце автор на примере бота для телеграм разбирает вариант конфигурирования логера. По каждому вопросу есть ссылка на офф документацию питона.

#python

Итерируем всякое

Статья с кликбейтным названием – 10 итераторов, о которых вы могли не знать и реально интересным содержанием.

Автор начинает по классике, объясняя, что такое итератор, как реализовать собственный итератор, проходится по генераторам, протоколу последовательностей и перечислениям.

Кстати, бывают собеседования, где реально просят реализовать свой итератор. Ситуация неоднозначная: с одной стороны, знать внутреннее устройство итератора полезно, и вопрос может быть подходящим для выявления понимания у джуна. С другой стороны, на практике редко требуется лезть туда ручками. Если нужно – всегда можно посмотреть в доку, запоминать смысла нет. В итоге по бесполезности напоминает вопрос о тестировании карандаша.

Из действительно любопытного отметим:
– iter может принимать два аргумента. Второй аргумент – элемент, на котором будет сгенерировано исключение StopIteration
– можно итерироваться по стандартному потоку ввода. Объект stdin итерируемый
– можно итерироваться по содержимому каталога. В модуле pathlib есть итератор iterdir
– можно итерироваться по строкам csv-файла, применив функцию iter к объекту csv_reader

Итераторы окружают питонистов. Даже если постоянно используете Python в профессиональной деятельности, найдете что-то интересное. Статья исключительно практическая. Бери и используй.

#python

Как ускорить приложение на FastAPI

Важно понимать потенциальные узкие места вашего приложения, и что можно подкрутить в том или ином случае.

Отличная практическая статья, показывающая, как можно ускорить своё приложение. Примеры из статьи выложены на github, поэтому можно потрогать ручками.

Ребята не открывают ничего супер нового, просто берут приложение на fastapi и показывают набор классических приёмов для ускорения работы.

Рассматриваются:
– многопоточность
– асинхронность
– redis для кеширования

А в качестве бонуса – статья о KeyDB, интересной альтернативе привычному всем редису, на которую стоит посмотреть.

#python

Асинхронное взаимодействие сервисов с применением Kafka

Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.

У нас были посты для более глубокого погружения в Kafka. Например, тут в одной статье рассказывают самые основы, в другой разбирают неочевидные проблемы, возникающие на практике.

#python #procode

Попробуйте ruff

Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.

Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.

Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.

Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff

Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.

#python

Tracing Python

Обычно для отслеживания работы кода достаточно отладчика в любимой среде разработки. Но если, например, проблема не воспроизводится локально, приходится расчехлять что-то большее…

В статье автор приводит всевозможные способы трассировки кода, останавливаясь на возможностях каждого:
— sys.settrace
— самописный logging-декоратор
— autologging
— icecream
— snoop и birdseye

В дополнение из наших постов: статья про разухабистое логирование, где одним из аспектов является поиск узких мест.

#python

Я люблю питон, и вот почему он меня бесит

Специалист выделяется тем, что для своего инструмента он понимает сильные и слабые стороны. Поэтому прошу: статья про кривые и косые вещи в питоне.

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

Динамические импорты дают свободу (как удобно прямо в функции что-то для отладки импортировать и потом убрать), так и определённые боли. А если импорт упадёт, а вы импортировали в рантайме? Это точно не то, что вы бы хотели.

Интересно было прочитать про legacy с потоками и процессами. Выглядит забавно.

Микс из разных стандартов именований прямо в модуле logging стандартной библиотеки забавен. Я всегда тыкаю в logging, когда хочу показать camelCase :)

С async в python действительно непросто. Но у нас был достаточно хороший гайд на этот счёт, вливайтесь.

Обратите внимание на блок про символьный ад. Меня всегда веселило, что 1 является числом, (1) тоже просто число, а 1, (с запятой) уже кортеж. Кстати, вы знали, что создание списка с помощью [] немного быстрее, чем создание с помощью list()?

С указанными автором нюансами про декораторы никогда не сталкивался. А вы? А вот с необходимостью прервать с помощью break сразу два цикла сталкивался неоднократно. Приходится некрасиво костылить, к сожалению.

Про наличие map/filter одновременно с comprehensions автор немного недоговаривает. В целом не существенно, но в статье List Comprehension vs Map этот вопрос рассматривается подробнее.

Огромная боль, что нет аннотации исключений. Я как-то советовал новичкам для обработки исключений смотреть справку по функции и самому в docstring тщательно прописывать исключения. А потом я посмотрел справку на open. В описании есть только порождение IOError. А на самом деле функция open может выбрасывать угодно — IsADirectoryError, PermissionError, FileNotFoundError... И узнать это нельзя.

Какие WTF в питоне больше всего забавляют вас?

#python

Да, у нас есть тесты. А толку?

50-минутное закрытое видео про тесты с конференции PiterPy от Николая Хитрова. Начинается видео с лирики и мемов, а потом разгоняется и проходит по ключевым темам с кучей ссылок на полезные тулзы. Покрытые темы:

— Концепция AAA (Arrange-Act-Assert) и линтер flake8-aaa

— Переход к GWT (Given-When-Then) и интересный способ применения тест-классов для группировки пользовательских сценариев. Кстати, впервые я вижу понятное объяснение преимуществ GWT, потому что в большинстве источников ставят равенство между AAA и GWT

— Что должны проверять тесты и как dirty-equals вам может помочь. Тут же предлагаются библиотеки для декларативной проверки сложных структур

— Snapshot asserts для сложных данных с библиотеками syrupy и assertpy

— Фикстуры, их область применения и полезные инструменты вроде построения графа фикстур pytest-fixture-tools

— Инструменты для борьбы с нестабильными (flaky) тестами

— Инструменты для генерации данных в тестах, в том числе генерации тесты по контракту

— Обсуждение классической пирамиды тестов E2E, интеграционных и юнит-тестов

— Какие зависимости в тестах мокать, а какие запускать при тестах

— Плотно обсуждаются mock-и и stub-ы

— Тулзы для профилирования и ускорения тестов за счёт параллельного запуска или запуска только изменённого кода

#python #youtube

Мой взгляд на новые фичи python3.10-3.12

Cмотрим на полезные нововведения в питоне последних лет — улучшенные f-строки, дополнения к исключениям, объединение нескольких with, pattern matching. Лёгкая статья на пикабу / VC / vk, код примеров на гитлабе. А какие фичи прочно вошли в ваш код?

#devfm #python

Стрим: разбираем Fastapi + Docker

Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.

В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке — код на гитлабе, проект в докере, в процессе используем Postman и смотрим web console браузера.

Предыдущий стрим про разработку небольшого проекта python-students.

#devfm #youtube #python
#СоерКлуб

Docker в каждый дом

Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.

Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.

#skills #sudo #devfm

Таки посмотрите на uv

Мы уже писали о быстром пакетном менеджере для Python — uv. Кто-то уже успел его пощупать? Я затащил его в несколько своих проектов — полёт нормальный. В продакшн хотели затащить, но так и не нашли весомых причин.

На днях вышла статья — A year of uv: pros, cons, and should you migrate. Автор в восторге от uv, и когда постарался упомянуть минусы, то даже от них скорее в восторге. В итоге текст — отличный вариант вдохновиться на использование этого инструмента. А если хотите узнать про подводные камни — залетайте в комменты, там автору уже насували.

#tools #python