Astral выпустили бета-версию своего тайп-чекера ty (версия 0.0.2). Я последний раз пробовал с ним играться весной, когда его только анонсировали и тогда он был откровенно сырым. Попробовал сейчас по-быстрому (`uvx ty check` если в проекте уже есть uv), вот первые впечатления:

- Действительно супер быстрый, с mypy не сравнить
- Очень подробный отчет о найденных ошибках в консоли, мне нравится
- Ругается на то, на что mypy не ругается, но я пока его не конфигурировал
- Часть проблем в коде, которые он нашел выглядят валидными, вторая часть спорная но наверное это можно побороть покопавшись в настройках

В целом выглядит интересно, на праздниках немного глубже покопаюсь - насколько действительно можно тащить в реальные проекты.

Ссылка на анонс https://astral.sh/blog/ty

Есть такой относительно популярный LLM-gateway/SDK — LiteLLM. Он позволяет единообразно вызывать разные облачные LLM (в том числе из Vertex, Bedrock, Azure и т.д.).

Вчера его скомпрометировали: в PyPI выпустили две версии — 1.82.7 и 1.82.8 — которые, например, крадут ключи из .ssh. Если вы его используете, самое время проверить, не задело ли вас это и если задело — срочно бегите менять ключи.

Сейчас PyPI поместил проект в карантин, и скачать эти версии уже нельзя. Подробности от разработчиков: https://github.com/BerriAI/litellm/issues/24518

Оригинальный issue на GitHub атакующий заспамил комментариями в стиле “Thanks, that helped!”, чтобы усложнить дискуссию и, видимо, выиграть себе время: https://github.com/BerriAI/litellm/issues/24512

Прикольный проект — интерпретатор «старого» Бейсика на Python. Сам проект маленький, всего около 1000 строк, поэтому, если вам интересно немного разобраться в том, как работают интерпретаторы, рекомендую посмотреть: https://github.com/nedbat/acidica

Вышла новая версия Ruff 0.16. Казалось бы, минорный релиз, но на самом деле нет. Теперь по умолчанию включено 413 правил вместо 59, поэтому, если в конфиге у вас не зафиксирован список правил, используемых на проекте, вас ждёт сюрприз.
Ради интереса прогнал Ruff на своём пет-проекте, где до обновления всё было зелёненьким. После перехода на 0.16 получил: Found 50 errors, 34 fixable. Пойду чинить 🙂

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

Ченджлог в блоге Astral: https://astral.sh/blog/ruff-v0.16.0

GitHub запустил пару полезных фич для безопасности CI.

Во-первых, Malware Alerts. Эта штука проверяет, нет ли зависимостей проекта в базе OpenSSF Malicious Packages, и, если находит совпадение, присылает алерт. Глобально включить её пока нельзя — только отдельно для каждого репозитория. Я у себя уже включил, вот тут инструкция https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configure-malware-alerts

Вторая фича - автоматическое обнаружение и блокировка небезопасных CI-пайплайнов. Если workflow выглядит потенциально вредоносным, GitHub не запускает его, пока участник с правами на запись не подтвердит запуск. Пока это работает только для публичных репозиториев.
Если интересно подробнее почитать, как могут выглядеть подобные атаки, вот хороший разбор: https://www.stepsecurity.io/blog/introducing-secret-exfiltration-protection-for-github-actions

Вышла библиотека django-orjson, которая позволяет легко перевести Django и DRF на быстрый orjson. В комплекте — JsonResponse, renderer и parser для DRF и даже сериализатор для сессий.
В принципе, идея не новая: мы у себя перевели DRF на orjson ещё года четыре назад. Но с готовым пакетом это будет гораздо проще сделать.

Тем, у кого плюс-минус нагруженный проект или просто большие JSON-запросы и ответы, рекомендую присмотреться: https://adamj.eu/tech/2026/07/15/introducing-django-orjson/

Поддержка free-threading в библиотеках сейчас один из ключевых блокеров перехода на free-treading. Поэтому я с интересом читаю статьи, которые публикуют на этот счет разработчики библиотек - не то чтобы мне это было нужно для работы, просто очень интересно. На днях наткнулся на статью, про оптимизацию NumPy - проблема была в том, что с отключенным GIL, ThreadPoolExecutor все равно работал медленнее, чем ProcessPoolExecutor. Если вам такое интересно - рекомендую почитать, но если кратко:

- Убрали локи там, где можно было обойтись без них
- Где-то перешли на immortal-объекты, чтобы перестать дергать счетчик ссылок
- Пересели с системного malloc/free на cpython-овский аллокатор, который лучше масштабируется на большое количество потоков

В результате бенчмарк вместо 44 секунд на 32 потоках начал отрабатывать за 1,5 секунды (при использовании процессов - 6 секунд). Подробнее в статье - https://labs.quansight.org/blog/scaling-numpy-on-free-threaded-python

Вместе с прогрессом llm-ок растет нагрузка на мейнтенеров проектов, это не новость и мы много раз обсуждали это в подкасте. Но вот подъехала статья с нитересными графиками по нагрузке именно связанноы с безопасностью:

- Security-отчеты на github - ~40 за весь 2025 и уже 175 за первую половину 2026
- Полноценные CVE - ~20 за 2025 и столько же только за первую треть 2026, т.е. за весь год предполагается рост в три раза

То есть рост нагрузки очень значительный, сама статься состоит почти из одних графиков https://hugovk.dev/blog/2026/security-line-goes-up/

Вышел релиз Django 6.1. Изменений не очень много:

- QuerySet.fetch_mode позволяет более гибко управлять тем, что происходит при обращении к незагруженному полю модели - делать запрос в базу, делать запрос загружая связанные сущности одним запросом или выдавать исключение. Выглядит как действительно полезная фича
- on_delete для ForeignKey теперь можно перевесить на уровень базы данных через SQL ON DELETE, раньше это делалось python-логикой
- В ORM добавлены функции для генерации UUID v4 и UUID v7 на стороне БД
- Всякие улучшения для Content Security Policy, настройки отправки email теперь конфигурируются через словарь и много всяких других мелочей

Полный ченджлог тут https://docs.djangoproject.com/en/6.1/releases/6.1/

Запустили опрос python-разработчиков про типизацию - в авторах опроса Astral, JetBrains, Microsoft, Meta, discuss.python.org - т.е. очень многие из тех кто реально занимается типаии/туллингом. Это ежегодная история, предыдущий отчет тут https://engineering.fb.com/2025/12/22/developer-tools/python-typing-survey-2025-code-quality-flexibility-typing-adoption/ - мы кажется обсуждали его в подкасте.

Если вы активно используете аннотации типов - сходите пройдите, важно давать обратную связь разработчикам, я уже прошел https://www.surveymonkey.com/r/python_typing

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

Django 6.2 LTS в апреле 2027 станет последним релизом со "старой" нумерацией, в январе 2028 выйдет уже Django 2028. https://www.djangoproject.com/weblog/2026/aug/10/annual-release-cycle/