PyLounge - программирование на Python и всё о Айти 🐍

12 лет в университете Так уже вышло, что 12 лет назад я поступил в университет в моем городе. Успел и поучиться, и попреподавать, и пописать диссертацию по техническим наукам. Поэтому тема образования не дает мне оставаться равнодушным. За 12 лет я повидал многое - от невероятных историй успеха до бесконечно грустных потухших глаз. Потухшие глаза и полная потеря мотивации студентов это следствие разрушенных ожиданий. К сожалению, как говорил Аршавин, наши ожидания это наши проблемы. Поэтому я подготовил материал, который поможет вам снять розовые очки и выправит ожидания) Я не буду говорить нужно ли получать образование в ВУЗе или нет. Это тема для бесконечного холивара. Просто я попытаюсь управлять вашими ожиданиями, если вы уже приняли решение поступить в университет или только раздумываете об этом. Я бы очень хотел, чтобы этот материал попался раньше мне и всем моим студентам, но рад, что он попался вам и, надеюсь, чем-то помог🙂 https://habr.com/ru/articles/703290/

Пришел, почистил, положил или как сбросить кэш и не уронить бэкенд Базовая ситуация - фронт кэширует отрендеренные страницы в Redis. Катим новый релиз, поменялся контент, по хорошему кэш надо инвалидировать. Не медля ни секунды, полный газ

redis.flushdb()

НО независимо от того, удаляет Redis ключи синхронно или асинхронно, с точки зрения приложения ключи исчезают одновременно (почти). Значит тысячи запросов одновременно промахиваются мимо кэша и отправляются прямиком на бэкенд. В общем (и целом) случае это cache stampede. Накладывает на союзника пик нагрузки на БД. Прежде чем чинить, давайте решим какие конкретно проблемы мы решаем: 1. Массовый cache miss после flushdb = все ключи протухают в одну секунду. Лечится это "размазыванием" инвалидации во времени. 2. Реальный Stampede на одном горячем ключе, то есть проблема когда именно один популярный ключ протухает, и N одновременных запросов все попадают (🤡) в miss и все бегут перегенерировать одно и то же. Тут нужно что-то типо single-flight или stale-while-revalidate. Размазываем протухание во времени В данном случае не просто delete, а expire с разными короткими TTL, чтобы промахи размазывались по окну, а не ударили разом. Окну? Хорошей идеей кажется взять что-нибудь типо log(n), но реальное ограничение - не размер кэша, а сколько страниц в секунду способен снова отрендерить бэкенд. Эмпирически неплохой считается стартовая оценка n / rebuild_rate, где rebuild_rate это пропускная способность бэкенда по перерендеру страниц. В реальности пропускная способность бэкенда плавающая. Она зависит от текущей нагрузки на БД, лунных суток и сложности рендеринга конкретной страницы. В идеале rebuild_rate сделать адптивным. Брать его из метрик (утилизация connection pool базы, p95 latency эндпоинта рендера). Размазываем

def stagger_expiry(
    redis,
    pattern="malutka-frontend:*",
    window_seconds=None,
    rebuild_rate=200, 
    batch_size=2000,
):
    keys = list({k for k in redis.scan_iter(pattern, count=1000)})
    n = len(keys)
    if n == 0:
        return 0 

    if window_seconds is None:
        window_seconds = max(1, math.ceil(n / rebuild_rate))

   random.shuffle(keys)

    pipe = redis.pipeline(transaction=False)
    for i, key in enumerate(keys, start=1):
        ttl = max(1, math.ceil(i / n * window_seconds))
        pipe.expire(key, ttl, lt=True)

        if i % batch_size == 0:
            pipe.execute()
            pipe = redis.pipeline(transaction=False)

    pipe.execute()
    return n

Хитрость в том, что ключам ставится короткий TTL, промахи размазываются по окну без единоразового дропа. shuffle - гарантирует, что распределение TTL не зависит от порядка обхода. А что по stampede на горячем ключе? Размазывание выше лечит только массовый синхронный промах. Один горячий ключ всё равно протухнет в свой момент, и в эту секунду по нему прилетит столько промахов, сколько было одновременных запросов. Это отдельная задача и решать ее надо отдельно: 1. через single-flight / лок на регенераци - когда N одновременных промахов по одному ключу схлопываются в один перерендер, остальные ждут результат. 2. stale-while-revalidate - отдаём устаревший контент, пока один воркер под локом строит свежий. По сути компромис между актуальностью и эффективностью, но на практике один из самых разумных способов убрать stampede. 3. probabilistic early expiration (XFetch) - это алгоритм перестраивает ключ вероятностно, тем чаще, чем ближе TTL и чем дороже пересчёт. Тоже достаточно популярный способ, но со своими нюансами. Так тривиальная на первый взгляд задача по сбросу кеша (с ростом RPS на проекте) превращается в увлекательное расследование и инженерную задачу. И здорово когда ты "на глаз" и заранее сможешь это заметить 🙂

Намедни прочитал "Чёрную книгу менеджера" от Славы Панкратова Основные тезисы кратко: 0. О проблемах и задержках нужно сообщать сразу, а не надеяться, что они исчезнут сами 1. Менеджера оценивают по результату, а не по оправданиям. 2. Настоящий руководитель берёт ответственность на себя, а не ищет виноватых. 3. Важно понимать, как бизнес зарабатывает деньги, и связывать работу команды с пользой для компании и клиента. 4. Главная задача менеджера - работа с людьми, их развитие, мотивация и организация команды. 6. Если сотрудник не справляется, сначала нужно выяснить: не понял, не умеет, не может или не хочет. 7. Основа управления - уважение к сотрудникам, коллегам и заказчикам. 9 из 10 стоматологов менеджеров в IT строго игнорирую все это :( Если вы ПМ или тимлид - строго рекомендасьен к чтению. Книжечка очень короткая, можно прочитать буквально за полчаса Сверху можно еще шлифануть моим материалом про говорение ртом :)

ФиналОчка по слою данных в Django - Proxy и Абстрактные модели

Продолжаем обсуждения слоя данных. Сегодня поговорим про Manager и QuerySet в лучшем фреймворке современности - Django

Появился вайбик поделиться своими "записками сумасшедшего". Первая порция - размышления на тему моделей в крупных и не очень Django-проектах

Анонс стрима: "работаем над lazy import'ами в CPython и плачем под аниме" (на превью - я на стриме) Мы с @nkhitrov_blog, @fastnewsdev и Денисом Аникиным (в 2026 и без тг канала!) решили замутить стрим по питону и ... новый канал на ютюбе под названием "Вялые Питоны". Подписаться уже можно вот тут: https://www.youtube.com/@SluggishPythons О чем будет канал? - Менее душный и более мемный чем мой основной - Все еще про питон и всякие хардкорные штуки внутри - Шутки, пиво, лень, слезы - Разные новые форматы, которые мы будем анонсировать постепенно - Разные интересные коллабы с веселыми и умными людьми Контент на старом канале останется таким же, каким и был. Я как раз вернулся из творческого отпуска. Скоро будет завоз по adaptix и django-modern-rest. И финал по vscode. О чем будет первый стрим? - Обсудим мотивацию и устройство PEP-810, потестим разные странные случае, Никита побомбит - Я запилю каких-нибудь пару тасочек в CPython, например https://github.com/python/cpython/issues/150459 - Если я буду плохо рассказывать, что там происходят - пацаны будут меня душить своими любимыми аниме - Если хватит времени, то еще починим setuptools / distutils, а то я все сломал - Выпьем пива со всеми желающими 🍻 Народ в чате проголосовал за время стрима в будний вечер, так что - записываем дату и время: Среда, 3 июня, 19:00 https://www.youtube.com/watch?v=W9Hd5dfxjIU Приходите задавать свои ответы и хорошо проводить время!

спросил чатгпт про лучшие каналы на ютюбе про питон на русском языке @v_dombrovsky @melnikovvv

Йо, мой материал про говорение ртом, кажется, победил в номинации "Карьера в IT" Хабр-конкурса Технотекст 8 Шорт-лист тута - https://habr.com/ru/companies/habr/articles/1039298/ Вам рекомендую ознакомиться со статьей, если раньше не видели или прошли мимо. А команде Хабра передаю поклон за проявленный интерес к работе :) P.S. Материалы других участников тоже сочнейший сок, почекайте, 100% найдете что-то интересное для себя. Ну и поддержите авторов плюсиками :)) P.S.S. Когда приедут подарочки будет распаковОчка P.S.S.S Хабр, с др

Неожиданно я, неожиданно снова про миграции, неожиданно на Хабре https://habr.com/ru/articles/1035830/

Там Никита aka автор Faststream aka AI-Энтузиаст aka AG2 мейнтейнер навалил НЕРЕАЛЬНОЙ БАЗЫ про агентов и агентскую разработку в своем материале на Хабре. Название статьи пусть вас не смущает - это не разгон или "рассуждение на тему". Это кладезь реально интересной и прикладной информации. Без которой, вероятно, в нашем новом дивном мире ИИ уже не обойтись 🙂 Газ читать, ставить плюсы и репостить https://habr.com/ru/articles/1029326/

Наконец-то среди бесконечного числа ютуб-роликов про ИИ, AI, XYI, LLM - можно с кайфом посмотреть что-то про Чунга-Джангу https://www.youtube.com/watch?v=7CNezDpcXwc

Вопреки плотнейшему загрузу я таки дорвался до того, чтобы пощупать Django Modern REST и сделать ролик! Это офк, не обзор фреймворка, я мое первое знакомство, которое, возможно, сподвигнет попробовать DMR и вас) https://www.youtube.com/watch?v=GLDaOWChvxI

Сочно попрогал на Django Modern REST. Впечатления пушка. Скоро будет ролик, а пока, кому интересно, можете потыкать небольшой примерчик проекта, который я смастерил https://github.com/Peopl3s/url-shortener-django-modern-rest-example

Наш опенсурсный слон Никита Соболев и его кореша сделали лучший REST фреймворк для Django. Газ знакомиться? https://habr.com/ru/articles/1017036/

Под выход новинОчки DMR наш друг @kondratevdev (ex-HH TeamLead, РТК Software Engineer, OpenSource-контрибутер) сделал Awesome Django Moderт REST репозиторий со всем важным и нужным. Маст хев для всех, кто собирается затестить DMR https://github.com/kondratevdev/awesome-django-modern-rest

django-modern-rest@0.1.0 – первый публичный релиз! Исходники: https://github.com/wemake-services/django-modern-rest Подробнейшая документация: https://django-modern-rest.readthedocs.io Пример настоящего приложения: https://github.com/wemake-services/wemake-django-template Первый анонс был уже какое-то время назад. Так что давайте повторять, что у нас тут происходит. Во-первых, у нас рекорд: еще нет ни одного релиза, а уже 560+ ⭐ на Гитхабе (сходите поставьте, кто еще не). Вижу, что люди ждут, вижу интерес. Спасибо!

import uuid
import msgspec
from dmr import Body, Controller
from dmr.plugins.msgspec import MsgspecSerializer

class UserCreateModel(msgspec.Struct):
    email: str

class UserModel(UserCreateModel):
    uid: uuid.UUID

class UserController(
    Controller[MsgspecSerializer],
    Body[UserCreateModel],
):
    def post(self) -> UserModel:
        return UserModel(uid=uuid.uuid4(), email=self.parsed_body.email)

Фичи – Главная фича, которая вообще подтолкнула меня к такому проекту: инфраструктура Джанги. Тут есть буквально все пакеты на все случаи жизни. Но не было нормального REST фреймворка. В комментах я регулярно наблюдал, как люди ненавидят Джангу, но почти всегда говорят про DRF. Да, он был ужасен – но теперь он на свалке истории! – Все существующие плагины к родной Джанге должны работать – Официальная поддержка Джанго в одном файле, да, Джанга может быть настолько простой – Работаем с любыми моделями: pydantic, msgspec, TypedDict, dataclass, тд. Сериализация и валидация не прибиты гвоздями. А значит можно выбирать сериализатор под контроллер. Где-то msgspec + TypedDict для скорости. Где-то pydantic для более широких возможностей валидации. Можно писать свои – Скорость. Мы довольно быстрые. Самый быстрый Python фреймворк для REST в Django. По скорости можно сравнивать с FastAPI, мы всего лишь на 30% медленнее. Но у нас и Джанга вообще-то. Скорость будет улучшаться, есть разные интересные идеи – Типизация: типизировано всё! Но самое важное, типизацию не пихают вам в лицо. Нет огромных и сложных типов. Все просто, надежно и удобно. Поддерживаем mypy, pyright, pyrefly в самых строгих вариантах – Поддержка async везде. От вьюх и моделей до SSE. Никаких sync_to_async внутри – SSE! Без дополнительных костылей: просто работает (с валидацией сообщений и возможностью строить бизнесовые ADT поверх типов сообщений и крутейшей схемой) – Семантика. Одна из ключевых фичей: мы очень сильно упоролись по генерации схемы. Добавил auth= в контроллер? В списке ответов появился 401 статус код автоматически. Возвращаешь ответ, заголовок, куку, которой нет в спеке? Во время дебага – случится ошибка валидации. На проде валидацию нужно отключать для скорости. Так мы гарантируем точность ответов и схемы. Не нравится схема? Все легко переопределить или вообще отключить – Swagger, Scalar, Redoc из коробки, легко настраивать – Работаем не только с json, поддерживаем content negotiation, можно писать свои парсеры и рендереры – JWT и DjangoSessionAuth из коробки, есть возможность отзыва токенов и сессий – Возможность писать заготовки контроллеров и полностью переиспользовать код. Писать плагины под dmr будет просто и удобно – Загрузка и отдача файлов (но на питоне такое очень осторожно надо делать, лучше на Rust) – Нет привязки к логике или DI (берите любой, например dishka). Мы просто парсим данные и возвращаем их. То есть: код не превратится в кашу из логики и фреймворка уже через 10 бизнес фичей – Удобная обработка ошибок на многих уровнях – Полная возможность для кастомизации. Можно даже поменять формат внутренних ошибок в рамках контроллера – Удобные тесты: polyfactory, pytest, schemathesis (проходим все правила из коробки) – Скилы для LLM для написания кода по OpenAPI спеке, llms-full.txt, Context7 для контекста – Но никакого нейрослопа внутри!

🤡 Как и обещал, ускоряем тегешку Рассказываю тайные знания как делать бизнес с 0 без мам и пап за 6 минут. 🤡 лайк, поддержка, коммент https://youtu.be/hIf22hitdu8 ⌨️ «ПИП ИНСТАЛЛ»