Недавно прошел Python Birthday Meetup 34 в офисе Сбера на Кутузовской. Это ежегодный митап в честь дня рождения питона (20 февраля 1991 года была опубликована версия 0.9.0). Мне понравилось. Но есть нюансы.

Главная сцена впечатляет – пока что лучший зал для конференций, который я видел. Но не хватило воды! Давайте купим Сберу куллер с водой, что ли. В общем, то ли они рассчитывали, что никто не придет, то ли планировал всё ChatGPT.

Всего было 3 доклада. Первый был самый душевный – про лень и нейросети. Получился общий разбор всех AI-решений на все случаи жизни: написание кода, генерация полноценных MVP с фронтом, суммаризация созвонов, генерация презентаций и т. д. Почти всё применимо, но без ручной «доработки» всё ещё никак. Из инструментов упоминались:

Для разработки: Github Copilot, Cursor, GigaCode

Автоматизация принятия PR/MR: qodo

Создание MVP вместе с UI: V0

Для создания презентаций: Presentation AI, Gamma

Второй доклад был про асинхронщину с кучей задачек, которые естественно почти никто правильно не решил. Приложу некоторые из них в отдельном посте. Было сложно, душно и интересно. Собеседование в Точку я бы не прошёл. Ну и про асинхронный DI (dependency injection).

В третьем докладе рассказали про кейс применения Pydantic и сравнение его с остальными «аналогами» (msgspec, cerberus, marshmallow). Главный вывод такой: Pydantic самый гибкий, мощный и достаточно быстрый. Он медленнее конкурентов на порядок, но точно не будет бутылочным горлышком. Кстати, под капотом, начиная со второй версии, он написан на Rust.

Ещё успел пообщаться на стойке с ребятами из Сбера. К моему удивлению, в большинстве команд теперь доступна полная удалёнка; раньше был только гибрид (надо бы проверить на HH). Ну и, конечно же, спросил про бюрократию и объяснительные за всё подряд. Говорят, такого в большинстве команд нет. Хотя я слышал другое. Верим?

#meetups

На днях обратил внимание на то, что ruff подчищает многие импорты из typing. Это оказалось правило UP035, которое заменяет устаревшие импорты на актуальные.

Пошел искать, когда typing успел стать устаревшим. Дело оказалось в PEP 585 (https://peps.python.org/pep-0585/) начиная с Python 3.9. Вот это да!) Там прямым текстом написано "Importing those from typing is deprecated."

По ссылочке можно найти полный список того, что теперь нужно импортировать исключительно из collections.abc.

Pycharm кстати не в курсе и в первую очередь предлагает подтянуть всё из typing, а не collections. Может скажем им?)

Оказывается существует модуль для обнаружения кодировки текста. Называется chardet. Под капотом оно анализирует частотность символов и структуру, находя закономерности, которые есть у разных кодировок.

Использовать максимально просто:

import chardet

# Пример текста в неизвестной кодировке
text_bytes = "Привет, мир!".encode("windows-1251")

# Определение кодировки
result = chardet.detect(text_bytes)

print(result)

Вывод следующий:

{'encoding': 'windows-1251', 'confidence': 0.99, 'language': 'Russian'}

#python

Вопрос: Как работает Garbage Collector в Python?

Это прям классика, встречается почти каждый раз. Если перечислите три основных механизма - уже будет достаточно :)

Ответ:

Здесь стоит выделить три ключевых механизма:
1. Подсчёт ссылок. Когда счётчик ссылок на объект падает до нуля, он удаляется.

2. Разрешение циклических ссылок. Если два объекта ссылаются друг на друга, их счётчик не упадёт до 0. Здесь нам понадобится альтернативный способ. Для разрыва циклов осуществляется обход всех объектов от "корня". Все объекты, которые не были найдены при таком обходе считаются "недостижимыми". Это и есть наши циклы и GC их удаляет.

3. Деление объектов на поколения.
Для оптимизации работы GC существует механизм "поколений". Новые объекты стартуют с generation 0. А после нескольких сборок мусора перемещаются в следующее поколение. Более старшие поколения проверяются реже, что экономит ресурсы.

#собесы

Так, 300 подписчиков сегодня празднуем или нет? 🤨

Будьте осторожны со своими желаниями. Нейросеть может их не понять 😂

Всех с пятницей!)

Вышла первая бета Django 5.2. Релиз ждём в апреле.

Из интересного:
- Научили shell импортировать модели автоматически. Но кажется уже все привыкли к shell_plus.
- Доехала поддержка композитных первичных ключей (pk из нескольких полей).
- Теперь у base.html есть блок extrabody для добавления своего кода перед закрытием </body>, может быть удобно для кастомизации.
- Еще больше методов получили асинхронную версию. UserManager.acreate_user(), User.ahas_perm() и т.д
- method_decorator() научился оборачивать асинхронные методы.
- Добавили предупреждение при запуске через runserver о том, что его нельзя использовать в проде. Кажется не поможет...
- В миграции завезли AlterConstraint, чтобы каждый раз не пересоздавать и не удалять констрейнты.
- Порядок полей в .values() и .values_list() теперь точно соответствует переданному. Соответственно .union() в таком случае гарантировано даст ожидаемый результат.
- Появились классы Deserializer для гибкого управления десериализацией. Никогда не было необходимости в этом, но выглядит хорошо.
-reverse() теперь принимает query и fragment keywords. Думаю стоит попробовать.
- 5.2 поддерживает Postgres от 14 версии и выше.

Подробности тут: https://docs.djangoproject.com/en/dev/releases/5.2/

https://fi-le.net/pypi/ смотрите что нашел. Визуализация Python-пакетов из PyPI на основе зависимостей. Получаются некие "кластеры", где можно найти наборы пакетов из каждого направления разработки. К примеру: pytest, pytest x-dist, pytest-cov.
Либо openai, tiktoken, langchain.
Уверен, что каждый увидит для себя что-то новое 👍

Всегда было интересно какой прирост на самом деле дает обновление Python на свежие версии. Будет ли прирост вообще? А может мы просядем в RPS и станет хуже?

Недавно собрался с силами и на коленке собрал бенчмарк на FastAPI. Под капотом реализован CRUD и запуск контейнеров с разными версиями питона. На каждой версии питона выполняется нагрузочное тестирование и сохраняется статистика.

Для большей объективности на каждом эндпоинте выполняются максимально "типичные" операции. Это запись в БД, чтение из файлов, обращения в кэш, расчет каких-либо значений и т.д.

Удалось переиспользовать одни и те же версии пакетов почти везде (были проблемы с 3.8 и 3.13). Так что влияние версий пакетов с различной реализацией внутри - минимально.

И того - Python 3.11 самый быстрый!
А сколько же разговоров было про оптимизации в 3.12 и 3.13...

Выглядит это всё интригующе. Почему 3.11 получился быстрее 3.13?) Надо копать дальше 🤨

#python

Невероятно, но факт.

Это очень интересный пример "внутренних" оптимизаций питона. Догадаться невозможно - нужно знать.

Многие привыкли, что [:] и вызов конструктора (list()) создают копию объекта. Но если перед нами неизменяемый объект, то всё может быть по другому. Такой объект под видом копирования может вернуть тот же объект, а не копию 🤨

Так же есть интересный пример с frozenset. Мы можем вызвать frozenset.copy() и это вернёт не копию, а всё тот же объект.

#python

Свершилось. Наконец-то сменил кресло на нормальное. Настраивается всё: изгиб поясницы, глубина седушки, положение подголовника, высота подлокотников.
Вот такая конфигурация получилась:
https://www.metta.ru/constructor/?top=S-30.D.15.A9

И это еще один повод напомнить - не покупайте геймерские кресла. Там нет ничего ни для комфорта, ни для здоровья. Для сомневающихся могу порекомендовать посмотреть https://youtu.be/pI4tDxRElWI?si=KWkQJOskvCSqkbSA

Как-то сегодня никто нормально не пошутил. Только Тинёк про кэшбек на камушки с пляжа и Razer выдал классический кринж-девайс.

Рассказывайте, какие еще первоапрельские приколы увидели. Может я просто пропустил.

А в 2009 году вышел PEP 401, в котором объявили о замене оператора != на <> и отказе от CPython 😂

https://peps.python.org/pep-0401/

Ну что, еще помните для чего нужны __slots__? Про них все слышали, но никто не использует 😅

Идея слотов проста - каждый раз, создавая экземпляр класса питон хранит все объекты в словаре __dict__. У словарей есть свои накладные расходы. А если мы указываем __slots__, то теперь для хранения используются кортежи. Они экономнее и быстрее.

Разница в памяти около 30% на ровном месте. Есть и прирост в скорости создания экземпляров. А так же в скорости доступа к атрибутам.

Есть особенности:
- Слоты не наследуются. У каждого дочернего класса нужно прописывать заново.
- Нельзя динамически добавлять атрибуты в класс
- При указании слотов пропадает поддержка слабых ссылок. Лечится добавлением __weakref__ в слоты вручную.

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

Простой пример тут

#python

Все становится только хуже 😂

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

⚙️ Round Robin (RR)
Раздаёт запросы по очереди — 1→2→3→1...

✅ Простота и скорость
✅ Работает «из коробки» почти везде
❌ Не учитывает загрузку сервера
❌ Если железо на серверах разное — слабый сервер захлебнётся, пока более мощные будут простаивать
❌ Не учитывает сложность запросов. На один сервер может упасть десяток долгих POST-запросов, пока другие получат простой GET и будут простаивать

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Weighted Round Robin (WRR)
То же самое, что и RR, только с возможностью указать “вес” сервера. На мощный сервер — 3 запроса, на слабый — один запрос.

✅ Учитывает разную мощность железа
❌ Вес статичен
❌ Легко забыть обновить веса в конфиге при изменениях
❌ Также не учитывает сложность запросов

Где есть: везде (nginx, haproxy и т.д.)

⚙️ Least Connections (LC)
Направляет трафик туда, где меньше активных соединений

✅ Учитывает текущую "загруженность"
✅ Идеально для долгих сессий (WebSocket, RDP)
❌ Не различает лёгкие и тяжёлые соединения
❌ Игнорирует мощность железа

Где есть: haproxy, traefik

⚙️ Least Response Time (LRT)
Измеряет время ответа сервера и шлёт туда, где быстрее

✅ Умный выбор по реальной скорости
✅ Быстро реагирует на "тормоза"
❌ Чувствителен к сетевым "скачкам"
❌ Нужно заморочиться с health check’ами

Где есть: haproxy (встроенно), nginx (с Lua/расширениями)

⚙️ IP Hash
Клиенты с одного IP всегда попадают на один сервер

✅ Простая привязка сессии без кук
✅ Подходит для stateful-приложений
❌ Перегрузка, если много клиентов за одним NAT
❌ Удаление сервера = обрыв сессий

Где есть: nginx, haproxy

⚙️ Resource-Based (Адаптивная)
Агенты на серверах следят за CPU, RAM, I/O и передают данные балансировщику.

✅ Максимальная точность по загрузке
❌ Требует настройки агентов, метрик и логики

Где есть: traefik, haproxy (Lua), кастомный nginx

Отдельно стоит упомянуть health check’и. Если TCP-порт открыт — это ещё не значит, что всё работает. Надежнее использовать HTTP/HTTPS-запрос на специальный endpoint (например, /health) с проверкой внутренних зависимостей (доступность базы, очередей, кеша и т.д.). Это создаёт дополнительную нагрузку, поэтому настройке нужно уделить внимание — частота, таймауты, и какие компоненты действительно критичны.

P.S Естественно про каждый вид балансировки стоит почитать отдельно, все тонкости не уместятся ни в одну шпаргалку ✍️