Есть такой относительно популярный 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/

Вчера пишет мне Никита Соболев - так и так, собираем папку с каналами python-сообщества. Учитывая, что с большинством тех, чьи каналы в папке я знаком лично, на кого-то итак был подписан - рекомендую - https://t.me/addlist/o2_hXmp5nSUyODNi

Для тех, кто уперся в лимит телеги по папкам, вот просто список каналов:

• https://t.me/opensource_findings
• https://t.me/goduniblog
• https://t.me/cpython_notes
• https://t.me/nkhitrov_blog
• https://t.me/fastnewsdev
• https://t.me/pylounge
• https://t.me/blog_pogromista
• https://t.me/moscow_python
• https://t.me/tricky_python
• https://t.me/pymineral
• https://t.me/t0digital
• https://t.me/grigorycode

Пару недель назад я писал про то, насколько больше security-отчетов теперь приходит для CPython по сравнению с предыдущими годами. Казалось бы - берешь llm, она пишет тебе патч - и готово, profit. И тут как раз 1password опубликовали исследование, которое показывает, что это пока так не работает.

Они сгенерировали более 6000 патчей для 6 разных уязвимостей с помощью opus 4.8 и chatgpt 5.5, обе в версии для security-специалистов (т.е. там были убраны часть ограничений). Результат? Только 26% патчей полноценно устранили уязвимость. Ещё 20,1% проблему закрыли, но работа приложения изменилась, читай "побочные эффекты". Самое забавное, в 2,1% случаев проблема не была устранена, так еще и появилась новая уязвимость. Хуже того, в трети "успешных" 20,1% на самом деле llm-ка фиксила не первопричину проблемы, а конкретный пример атаки, описанный в промпте.

Вывод? Llm-ки очень удобны и могут ускорить разработку - но и голову тоже нужно включать и смотреть, что там интеллект нагенерил - ревьюить, править, тюнить. Ссылка на статью: https://1password.com/blog/why-ai-generated-patches-still-require-human-review

Есть такой язык - Mojo:

• синтаксически он близок к python
• дает возможность вызывать и исполнять питоновские библиотеки через cpython-рантайм (я не уверен, что это production-схема
• расходы на конвертацию и GIL никуда не деваются, но тем не менее)
• при этом сам язык компилируемый - есть и JIT, и AOT-сборка в бинарник
• работает с gpu из коробки

и в принципе выглядит довольно интересно.

И вот на прошлой неделе вышла версия 1.0 языка, то есть предполагается, что он достаточно стабилизировался. А на днях его заопенсорсили под apache 2.0 лицензией. Я его трогал совсем немного - когда сделали возможность вызова python-библиотек, но сейчас кажется хороший повод пойти поиграться. https://www.modular.com/blog/mojo-open-source