Zen of Python

06 August 2026 14:21

Python 3.15 добрался до rc1: ленивые импорты, frozendict и UTF-8 по умолчанию

4 августа вышел первый релиз-кандидат. Финал ожидается в октябре, так что смотреть, что придётся чинить, стоит уже сейчас. Самое заметное:

— PEP 810, ленивые импорты. Новый синтаксис lazy import json и lazy from json import dumps. Модуль не грузится, пока имя реально не тронули. Строго opt-in: меняется поведение только помеченных строк. Главные бенефициары — CLI-утилиты и тест-сьюты с тяжёлым деревом зависимостей.

— PEP 686, UTF-8 по умолчанию. Кодировка для I/O больше не зависит от системной локали. Откатить можно через PYTHONUTF8=0 или -X utf8=0 — и вот это стоит проверить заранее, если у вас Windows и legacy-файлы в cp1251.

— PEP 814, встроенный frozendict. Наконец-то неизменяемый словарь в ядре, а не в трёх конкурирующих пакетах на PyPI.

— PEP 798, распаковка в comprehensions. [*L for L in lists] для плоского списка, {**d for d in dicts} для слияния словарей — синтаксическая дыра, которая раздражала лет десять.

— PEP 799, семплирующий профайлер Tachyon прямо в стандартной библиотеке. Другой класс инструмента, чем cProfile: тот инструментирует каждый вызов и искажает картину на горячем коде, семплирующий периодически снимает стек и почти не мешает.

— JIT прибавил 6–7% среднего геометрического на x86-64 Linux и 12–13% на AArch64 macOS.

Плюс по мелочи: sentinel из PEP 661, TypedDict с типизированными extra-полями (PEP 728), TypeForm (PEP 747) и более внятные подсказки в AttributeError.

Полный список — в whatsnew, там же примеры кода и раздел с несовместимостями.

#python315 #cpython

Zen of Python

05 August 2026 08:05

Разбор HTML-страницы за 272 микросекунды вместо 15,3 миллисекунды

Бернат Габор собрал turbohtml, набор инструментов для HTML целиком на C: экранирование, разэкранирование, токенизация, запросы по селекторам, сериализация и операции с URL. Разбор страницы на 92 КБ занимает 272 мкс против 15,3 мс у BeautifulSoup, запрос по селектору 1,3 мкс против 20,8 мкс у lxml и 99,9 мкс у BeautifulSoup, токенизация 34,9 мкс против 435 мкс у html.parser и 836 мкс у html5lib. На плотном четырёхмегабайтном тексте escape отрабатывает за 4,98 мс против 12,7 мс у html.escape. Публикация от 18 июня обновлена 10 июля.

Скорость складывается из того, как обрабатываются байты. Обычный код ищет спецсимволы посимвольно, и процессор на каждом байте выполняет ветвление. Здесь байты обрабатываются пачками: SWAR складывает восемь байт в одно машинное слово и проверяет их арифметикой, SIMD делает то же самое сразу по шестнадцать байт одной инструкцией. Ветвлений в горячем цикле почти не остаётся.

🔘 длина результата сначала считается точно, потом выделяется одним куском и заполняется массовым копированием, вместо дописывания по мере разбора;
🔘 токенизатор сохраняет исходную ширину строки и компилируется в три варианта под UCS-1, UCS-2 и UCS-4;
🔘 чистые текстовые куски возвращаются как срезы без копирования, копия делается только когда она правда нужна;
🔘 переписывание css_path() с квадратичного перебора на индекс сократило пример со 112 мс до 0,9 мс;
🔘 список переиспользуемых обёрток ускорил find_all() с 1,9 до 1,4 мкс, но в сборке без GIL он отключён.

Автор оговаривает, что Callgrind считает инструкции, а не реальное время по часам, поэтому на него опираются только при сравнении вариантов. Корректность проверяется побайтовым сравнением с эталонными библиотеками, сборками с ASan и UBSan и фаззингом.

Что у вас парсит HTML в проде и сколько времени на это уходит?

@zen_of_python

Zen of Python

03 August 2026 08:42

Rust научился ускорять операции с плавающей точкой, сохраняя контроль за точностью

Если вы держите Rust под рукой для кусков, где Python не хватает скорости, в Rust 1.98 появился повод присмотреться. Новый API разрешает компилятору агрессивнее оптимизировать операции с плавающей точкой, но сохраняет контроль за точностью округления. Это значит, что Rust-код, который вызывается из Python, может считать быстрее без привычного компромисса «скорость против корректности».

Раньше в Rust не было стабильного способа управлять этим компромиссом. Теперь можно явно указать компилятору, где безопасно ускорять вычисления, а где важна минимальная погрешность.

Разобрался Itamar Turner-Trauring: если пишете Rust-расширения для Python или интересуетесь, откуда берётся скорость в числовых библиотеках, загляните.

Zen of Python

02 August 2026 08:05

Сервис убивало по нехватке памяти каждые несколько часов, но утечки в нём не было

RSS рос ступенями: 620 МБ, 890 МБ, 1,4 ГБ, 2,3 ГБ, 3,1 ГБ. Трафик, загрузка процессора и p99 при этом стояли ровно. Число объектов Python не увеличивалось, ни разбухшего словаря, ни списка, ни кэша найти не удалось. gc.collect() честно собирал циклический мусор, а RSS после него почти не опускался. Сакшам Шарма разобрал этот случай 8 июля.

Дело в разделении обязанностей. Сборщик мусора решает, какие объекты ещё достижимы, а аллокатор решает, вернутся ли освободившиеся страницы операционной системе. Освобождённый объект просто уходит обратно в кучу процесса, и пока в той же странице памяти лежит хоть один живой объект, отдать её ядру нельзя. У glibc malloc к этому добавляются кэш освобождённых блоков tcache и отдельные арены на каждый поток, так что многопоточный сервис держит несколько независимых запасов. В одном из примеров автора живые объекты занимали около 700 МБ при RSS около 2,8 ГБ.

🔘 признак, отличающий это от настоящей утечки: tracemalloc показывает стабильный объём, а RSS продолжает расти;
🔘 лечение обошлось без единой правки в коде Python, jemalloc подключается через LD_PRELOAD;
🔘 в продакшене к нему добавили PYTHONMALLOC=malloc и MALLOC_CONF=narenas:2,background_thread:true;
🔘 автор сообщает примерно о вдвое меньшем потреблении оперативной памяти после перехода;
🔘 проверить гипотезу можно и без замены аллокатора, через MALLOC_ARENA_MAX=2 и вызов malloc_trim(0).

Оговорка автора: malloc не универсально лучше встроенного pymalloc, на миллионах мелких объектов выигрыш может оказаться обратным, поэтому замену нужно мерить на своей нагрузке.

Приходилось ловить рост RSS при стабильном числе объектов, и чем в итоге объяснялось?

@zen_of_python

Zen of Python

29 July 2026 08:05

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

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

🔘 в 0.140.0 от 24 июля класс Dependant разгрузили: вспомогательные функции с кешами вынесли наружу, объект теперь просто хранит данные. Бенчмарк памяти на графе зависимостей упал с 17,5 МБ до 1,1 МБ;
🔘 в 0.140.1 от 27 июля предел lru_cache для классификации вызываемых объектов подняли с 1024 до 4096: нашлись приложения, где зависимостей заметно больше тысячи, а на переполненном кеше выигрыш терялся;
🔘 в 0.140.2 в тот же день перестали удерживать плоские деревья зависимостей: бенчмарк графа маршрута ужался с 575 до 110,7 КБ.

Заодно в CI добавили замер памяти, так что рост потребления теперь виден прямо в пул-реквесте, а не в проде через полгода.

Замеряете память своих сервисов в CI или ловите такое уже на боевых машинах?

@zen_of_python

Zen of Python

27 July 2026 16:34

Видеофайл на 50 КБ может выполнить код на вашем устройстве

В FFmpeg нашли 16-летнюю уязвимость PixelSmash. Она живёт в декодере MagicYUV: AVI, MKV или MOV размером с картинку вызывает запись за пределами буфера и открывает удалённое выполнение кода. Серьёзность: 8.8 из 10 по шкале CVSS, то есть «высокая».

MagicYUV включён везде по умолчанию «для вашего удобства». Поэтому плееры, мессенджеры, NAS и облачные транскодеры принимают вредоносное видео без вопросов, лишь бы система сгенерировала превью.

Проверьте себя командой из материала: если в выводе есть magicyuv, обновите FFmpeg или пересоберите с флагом --disable-decoder=magicyuv. За 16 лет она успела разойтись повсюду.

Zen of Python

24 July 2026 08:03

В pyvenv.cfg предлагают записывать версию Python — появился PEP 838

Версию интерпретатора в pyvenv.cfg каждый инструмент записывает по-своему: где-то это поле version, где-то version_info, причём с patch-версией, которая устаревает после обновления интерпретатора. PEP 838, созданный 15 июля, предлагает навести здесь порядок к Python 3.16.

🔘 новый ключ python-version записывает только major и minor, например 3.16 — patch-обновления его не ломают;
🔘 создатели окружений должны будут писать python-version, чтение старых полей предлагается считать нежелательным;
🔘 интерпретатор сможет отказаться запускаться из окружения, если major/minor не совпадают;
🔘 окружения без нового ключа разрешено обрабатывать по старым полям или проверять через сам интерпретатор.

Автор PEP — Константин Шютце, референсные реализации уже перечислены для uv, virtualenv и CPython. Статус пока Draft.

Ловили ситуацию, когда venv молча работал с другой версией Python, чем ожидалось?

@zen_of_python

Zen of Python

23 July 2026 15:56

OpenCode: ИИ-агент для Python в терминале, который не уводит код в облако

Если вы предпочитаете командную строку графическим IDE, OpenCode может оказаться удобнее: он работает как TUI прямо в консоли, понимает контекст Python-проекта и рефакторит код с учётом всей кодовой базы, а не вставленного фрагмента.

Для питониста тут два полезных момента. Первый — локальность: провайдер подключается из вашей среды, файлы остаются на вашей машине. Второй: встроенный Pyright и режимы Plan/Build, которые либо показывают план правок, либо применяют его сразу. Ещё AGENTS.md позволяет явно прописать правила проекта: от стиля до команд запуска.

Для старта достаточно бесплатного ключа Gemini. Подробности в обзоре.

Zen of Python

18 July 2026 11:04

PyTorch — Python-библиотека для обучения и запуска нейросетей на процессорах и ускорителях. Версия 2.13 снижает расход памяти при обучении языковых моделей, ускоряет разреженное внимание на Mac и загружает safetensors напрямую.

🔘 nn.LinearCrossEntropyLoss объединяет последний линейный слой и функцию потерь, сокращая пиковый расход GPU-памяти до четырёх раз на моделях с большим словарём;
🔘 FlexAttention заработал на Apple Silicon;
🔘 torch.load() открывает safetensors без отдельной библиотеки;
🔘 появились Linux wheels для предварительных Python 3.15 и свободнопоточного 3.15t.

Заявленное ускорение FlexAttention примерно в 12 раз получено на конкретном разреженном шаблоне. Для плотного внимания SDPA остаётся быстрее. Сборки для Python 3.15 пока лежат в отдельном индексе PyTorch, а torch.compile с этой версией языка ещё не работает.

@zen_of_python

Zen of Python

16 July 2026 11:01

PyArrow — Python-библиотека для больших таблиц и колоночных данных Apache Arrow. Она читает файлы Parquet и помогает передавать данные между pandas, Polars, аналитическими движками и хранилищами без лишних преобразований.

В PyArrow 25 появились новые возможности для тензоров и шифрования Parquet:

🔘 Table преобразуется в Arrow Tensor;
🔘 списки многомерных массивов превращаются в FixedShapeTensor;
🔘 Parquet получил прямой API для ключей шифрования и расшифровки;
🔘 pa.OSFile принимает обычный файловый дескриптор.

Python-реализация Feather получила статус устаревшей. Сам формат продолжит работать через общий стек Arrow IPC. В релиз вошли 268 коммитов от 66 участников.

@zen_of_python

Zen of Python

14 July 2026 17:10

VPS в 2026: почему сервер тормозит, хотя метрики в норме

Вы смотрите на дашборд: CPU 40%, память не вся занята, а пользователи жалуются на лаги. Скорее всего, ваш VPS просто не получает тех ресурсов, за которые вы платите.

За несколько лет картина резко поменялась. Если раньше на одно физическое ядро приходилось 4–8 виртуальных CPU, то у бюджетных провайдеров сейчас норма — 10–16. Пока соседи по хосту спят, вы получаете мощность. Когда все просыпаются одновременно, гипервизор забирает CPU у вас. Это видно в метрике %st — steal time.

К этому добавились тяжелее ОС и стек. Ubuntu 24.04 при минимальной конфигурации занимает 3–5 GB RAM ещё до вашего приложения, а современный бэкенд часто тянет брокер, кеш, мониторинг и контейнеры. Разобрались, когда дешёвый VPS перестаёт тянуть и что с этим делать.

Zen of Python

13 July 2026 21:25

За @property и @staticmethod стоят дескрипторы

Каждый раз, когда вы вешаете декоратор на метод, Python тихо создаёт объект с методом __get__. Этот объект ловит обращение к атрибуту класса и решает, что вернуть — bound method, вычисленное значение или сам дескриптор.

В свежем HOWTO от Рэймонда Хеттингера разобрано, как именно это работает: от примера, который всегда возвращает десятку, до чисто-питонических реализаций property и __slots__. Гайд пригодится, если хотите перестать догадываться и начать предсказывать поведение своих классов.

Zen of Python

13 July 2026 15:46

На Tproger вышла история разработчика с 10 годами опыта: с инженерной частью у него всё было закрыто, а для своего дела не хватало другого — проверять идею, считать деньги, доводить продукт до рынка. Онлайн-курсы он бросал на середине, поэтому выбрал формат пожёстче: онлайн-магистратуру МФТИ по технологическому предпринимательству.

В обзоре: как совмещать такую учёбу с работой, почему реальная нагрузка выходит 20–25 часов в неделю вместо заявленных 10, где программа слабая и во сколько она обойдётся в 2026 году.

@zen_of_python

Zen of Python

12 July 2026 15:32

80% корпоративных программ геймификации ломаются на одном и том же месте

По данным AmplifAI, игровые кампании дают в среднем вовлечённость на 100–150% выше, чем классические подходы, а геймифицированный контент шерится в 12 раз чаще. При этом примерно 80% корпоративных программ геймификации не достигают целей. Спрос огромный, качество — низкое, а причина проста: делать это берутся не те люди.

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

Zen of Python

11 July 2026 09:33

Вышел mypy 2.2 — главное в релизе то, что тайпчекер научился закрытым TypedDict из PEP 728.

Что внутри:

🔘 TypedDict с closed=True запрещает любые ключи сверх объявленных — раньше лишние ключи в значении типа TypedDict были формально допустимы, и тайпчекер не мог на них ругаться;
🔘 закрытость делает надёжным сужение типов: в объединении Book | DVD проверка "author" in item теперь честно доказывает mypy, что перед ним Book;
🔘 работает и в классовом синтаксисе: class Book(TypedDict, closed=True);
🔘 завершена поддержка дефолтов типовых переменных из PEP 696 — и в старой записи TypeVar("T", default=int), и в новой class Box[T = int], включая рекурсивные дефолты;
🔘 mypy теперь уважает явно аннотированный тип возврата у __new__ — раньше он молча считал, что __new__ всегда возвращает экземпляр текущего класса;
🔘 поддержка TypeForm перестала быть экспериментальной.

Пользуетесь TypedDict для словарей с фиксированной структурой или в таких местах у вас dataclass и pydantic?

@zen_of_python

Zen of Python

06 August 2026 08:05

Как в CPython 3.15 убрали проверку из горячего цикла интерпретатора

JIT в CPython нужен поток исполняемых инструкций, значит интерпретатор должен уметь записывать всё, что выполняет. Ключевой вопрос в том, сколько за эту возможность платят программы, которым запись не нужна. Кен Джин описал 1 июля путь к решению, попавшему в 3.15.

Первый вариант: два отдельных интерпретатора, обычный и записывающий. Для интерпретатора на хвостовых вызовах это работало приемлемо, а на варианте с computed goto дало около 6% замедления на pyperformance. Одна из причин в том, что код интерпретатора на C фактически удвоился и перестал помещаться в кэш процессора. Второй вариант, флаг режима записи, убирает раздувание кода, но возвращает проверку ветвления в самый горячий путь, на каждую выполняемую инструкцию.

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

🔘 наивная реализация с двумя полноценными таблицами упирается в ту же проблему, это снова два интерпретатора;
🔘 трюк в том, что все записи второй таблицы указывают на одну-единственную инструкцию записи;
🔘 она пишет trace и передаёт управление обычной таблице, получается сужение потока и обратное расширение;
🔘 включение и выключение режима сводится к подмене указателя на таблицу, ENTER_TRACING() и LEAVE_TRACING();
🔘 в игрушечном замере медиана по 40 запускам составила 1,72 микросекунды без записи и 7,47 микросекунды с записью и JIT.

Автор оценивает накладные расходы максимум в 4,5x и сразу оговаривает, что сравнивать это с накладными расходами 900–1000x у PyPy некорректно.

Чем профилируете горячий Python-код сейчас и во сколько раз он от этого замедляется?

@zen_of_python

Zen of Python

04 August 2026 08:05

Шесть проверщиков типов для Python на одних и тех же исходниках

Справочник pydevtools прогнал mypy, pyright, Basedpyright, ty, Pyrefly и Zuban по скорости, строгости, выводу типов, поддержке в редакторах и лицензиям. Замеры делались на Apple Silicon, по пять запусков с отброшенным прогревом и очищенными кэшами, дата последнего обновления страницы 30 июля.

На библиотеке Rich, 38 тысяч строк: mypy 0,90 с, pyright 2,64 с, Basedpyright 2,35 с, ty 0,10 с, Pyrefly 0,17 с, Zuban 0,13 с. На SQLGlot, 76 тысяч строк: mypy 2,58 с, pyright 4,04 с, Basedpyright 4,33 с, ty 1,28 с, Pyrefly 0,32 с, Zuban 0,49 с.

🔘 в этом наборе ty обогнал mypy в 9 раз на Rich и в 2 раза на SQLGlot, Pyrefly быстрее в 5–8 раз, Zuban в 5–7 раз, pyright же оказался в 2–3 раза медленнее mypy;
🔘 параллельный режим mypy на проектах такого размера дал 1,2x и 1,3x вместо обещанных пятикратных;
🔘 в наборе тестов на соответствие спецификации типов из 141 пункта: Zuban 140, pyright 134, Pyrefly 130, ty 100, mypy 83;
🔘 mypy по умолчанию вообще не заглядывает внутрь функций без аннотаций, остальные разбирают их выводом типов;
🔘 расхождение видно на двух строках: после x = [] и x.append(1) pyright, Basedpyright и ty считают тип list[Unknown], а mypy, Pyrefly и Zuban выводят list[int].

Автор предупреждает, что процент прохождения тестов на соответствие не означает практической пользы: пункты в наборе неравноценны по важности, а инструменты в бете меняются быстро, так что цифры стареют.

Переезжали с mypy на что-то из нового поколения, и сколько чужих ошибок вылезло на неаннотированном коде?

@zen_of_python

Zen of Python

03 August 2026 08:05

uv 0.12.0: uv init теперь создаёт проект со сборочной конфигурацией

Astral выпустила uv 0.12.0 28 июля, первый крупный релиз после 0.11.0 в марте. Изменения касаются дефолтов инициализации, проверки хэшей и разбора архивов пакетов.

Раньше uv init создавал плоскую структуру без сборочной системы, и сборочную конфигурацию со структурой src приходилось добавлять отдельно. Теперь проект сразу пригоден для сборки.

🔘 uv init прописывает [build-system] на uv_build, кладёт код в src/<name> и добавляет точку входа в [project.scripts], прежнее поведение возвращает флаг --no-package;
🔘 отклоняются исходные дистрибутивы в форматах .tar.bz2 и .tar.xz, по PEP 625 допустим .tar.gz, старые .zip пока принимаются ради совместимости; заодно запрещены записи со сжатием bzip2 и LZMA внутри wheel;
🔘 wheel, способный перезаписать сам интерпретатор (файлы вида Python, python.py, Python.exe, записи в .data/scripts), больше не устанавливается;
🔘 режим предрелизов по умолчанию сменился с if-necessary-or-explicit на if-necessary, то есть предрелизная версия ставится только когда без неё зависимости не разрешаются;
🔘 директива --require-hashes внутри requirements.txt действительно включает проверку хэшей, а хэши только по MD5 отвергаются, нужен минимум SHA-256;
🔘 строже валидируется pylock.toml: обязателен массив packages, имя файла допустимо только вида pylock.toml или pylock.dev.toml, проверяется размер артефактов.

Авторы пишут, что большинству обновление не потребует правок. Исключение составляют проекты, где зафиксирована верхняя граница сборочного бэкенда: там нужно поднять до uv_build>=0.11.32,<0.13.

У вас в CI uv закреплён конкретной версией или подтягивается последний?

@zen_of_python

Zen of Python

30 July 2026 08:05

Донхи На и Никита Соболев предложили PEP 841: запись f{1, 2, 3} создаёт frozenset, f{'a': 1} создаёт frozendict, f{} даёт пустой frozendict. Черновик написан 16 июля, обсуждение открыли 20 июля, целятся в Python 3.16.

Сейчас frozenset({1, 2, 3}) сначала собирает обычное множество, потом копирует его в неизменяемое, и на каждом выполнении ищет имя frozenset в области видимости. Соптимизировать это компилятор не может: имя могут переопределить, а у вызова могут быть побочные эффекты. Один частный случай CPython уже спрямляет, но только справа от in. Присвойте тот же литерал переменной, и оптимизация исчезает.

Что предлагает PEP:

🔘 неизменяемость гарантирует сама грамматика, поэтому её не приходится выводить из того, как значение используется дальше;
🔘 константный f{...} сворачивается в один LOAD_CONST и попадает в .pyc, так что на каждом следующем выполнении конструирование бесплатно;
🔘 добавляются токен FLBRACE, четыре узла AST и две инструкции байткода: BUILD_FROZENSET и BUILD_FROZENMAP;
🔘 работают и генераторные выражения: f{x for x in xs}, f{k: v for k, v in items}, а также распаковка f{*xs} и f{**d};
🔘 f{ сегодня синтаксическая ошибка, поэтому старый код ничего не теряет. Запись f {1} с пробелом ошибкой и останется, путаницы с f-строками нет;
🔘 в стандартной библиотеке авторы насчитали около 105 вызовов frozenset и 65 вызовов frozendict, из них 46 и 22 можно переписать новой записью.

Большая цель за синтаксисом — подтолкнуть людей к неизменяемым контейнерам перед эпохой сборок без GIL и субинтерпретаторов: субинтерпретаторы уже делят между собой frozenset, на очереди frozendict. Про JIT авторы намеренно ничего не обещают, потому что руководящий совет в июне запретил новую разработку JIT в main до принятия отдельного PEP.

Читается ли f{1, 2, 3} лучше, чем frozenset({1, 2, 3}), или лишний префикс только запутает?

@zen_of_python

Zen of Python

28 July 2026 08:05

18 июля вышла последняя запланированная бета Python 3.15: около 298 исправлений, сборок и правок документации с прошлой беты. Дальше по плану релиз-кандидат 4 августа.

Что приедет в 3.15:

🔘 PEP 810 — явные ленивые импорты ради быстрого старта;
🔘 PEP 814 добавляет встроенный тип frozendict, а PEP 661 — тип sentinel;
🔘 PEP 799 приносит отдельный пакет для профилирования и Tachyon, семплирующий профилировщик высокой частоты;
🔘 PEP 686 делает UTF-8 кодировкой по умолчанию;
🔘 PEP 831 включает фреймовые указатели по умолчанию, чтобы системные профилировщики видели стек Python;
🔘 JIT заметно подтянули: 8–9% среднего геометрического прироста на x86-64 Linux против обычного интерпретатора и 12–13% на AArch64 macOS против интерпретатора с хвостовыми вызовами;
🔘 официальные 64-битные сборки под Windows перешли на интерпретатор с хвостовыми вызовами, а сборки под macOS теперь ставят поддержку свободной от GIL версии по умолчанию.

Команда просит библиотеки протестироваться на бете и выложить пререлизные колёса, но обычные прод-релизы советует придержать до 3.15.0rc1: ABI после четвёртой беты меняться не должен, гарантий до кандидата всё же нет.

Уже гоняли свои проекты на 3.15 или ждёте финального релиза 1 октября?

@zen_of_python

Zen of Python

25 July 2026 08:01

Robot Framework — фреймворк тестовой автоматизации на Python с keyword-driven синтаксисом. Первая бета версии 7.5 вышла 17 июля и открывает новый feature-цикл.

🔘 Libdoc понимает Markdown, а аргументы, возвращаемые значения и исключения можно документировать в Google Style — результат конвертируется в HTML;
🔘 тесты и tasks можно встраивать в Markdown-файлы через fenced-блоки robotframework, файлы .robot.md распознаются автоматически;
🔘 пользовательские console loggers регистрируются через --console и используют API listeners, Rebot поддерживает тот же механизм;
🔘 TimeoutExceeded теперь наследуется от BaseException — случайный except Exception: его больше не проглотит;
🔘 объявлены устаревшими встроенный Testdoc и неоднозначные tag patterns вроде XORY.

Пишете автотесты на Robot Framework или в вашей команде победил чистый pytest?

@zen_of_python

Zen of Python

23 July 2026 15:56

OpenCode: ИИ-агент для Python в терминале, который не уводит код в облако

Если вы предпочитаете командную строку графическим IDE, OpenCode может оказаться удобнее: он работает как TUI прямо в консоли, понимает контекст Python-проекта и рефакторит код с учётом всей кодовой базы, а не вставленного фрагмента.

Для питониста тут два полезных момента. Первый — локальность: провайдер подключается из вашей среды, файлы остаются на вашей машине. Второй: встроенный Pyright и режимы Plan/Build, которые либо показывают план правок, либо применяют его сразу. Ещё AGENTS.md позволяет явно прописать правила проекта: от стиля до команд запуска.

Для старта достаточно бесплатного ключа Gemini. Подробности в обзоре.

Zen of Python

23 July 2026 08:02

uv — пакетный менеджер и резолвер зависимостей для Python на Rust. Релиз 0.11.31 опубликован 22 июля и заметно докручивает workspace-сценарии и безопасность установки.

🔘 workspace-источники теперь могут ссылаться по пути на участников другого workspace, а .venv — указывать на централизованные окружения проектов;
🔘 в preview появилась настройка hash-algorithm на уровне конкретного индекса при генерации lockfile;
🔘 у uv audit — параметры audit.malware-check и audit.malware-check-url;
🔘 установщик отклоняет wheel и source-архивы, у которых имя пакета не совпадает с заявленным, включая обход через symlink-пути;
🔘 uv больше не повторяет запросы после ошибок проверки TLS-сертификата и вычищает учётные данные из ошибок Git fetch;
🔘 резолвер избавился от квадратичной работы при дедупликации транзитивных конфликтов.

Централизованные окружения через .venv-ссылку выглядят как шаг к «одна машина — один кэш окружений». Держите .venv в каждом проекте или уже пробовали выносить окружения в одно место?

@zen_of_python

Zen of Python

17 July 2026 11:02

Ruff — быстрый линтер и форматтер Python-кода. Он находит типичные ошибки, следит за стилем и импортами и автоматически исправляет часть замечаний.

В версии 0.15.21 появился экспериментальный флаг --add-ignore. Он добавляет ruff:ignore к выбранной строке и отключает правило только в этом месте.

Новое preview-правило UP051 находит устаревшие декораторы из abc и предлагает замену. Команда ruff format получила --extend-exclude для дополнительных исключений. Проверка Jupyter Notebook теперь ловит синтаксические ошибки отдельно в каждой ячейке. В релиз также вошли оптимизации и исправления автофиксов.

@zen_of_python

Zen of Python

15 July 2026 11:03

coverage․py показывает, какие строки Python-кода прошли через тесты, а какие остались без проверки. Его обычно запускают вместе с pytest, чтобы увидеть пробелы в тестовом наборе.

В версии 7.15.1 исправили HTML-отчёты. Метка контекста с </script> могла раньше времени закрыть встроенный скрипт и повредить страницу. Такая строка встречается, например, в имени параметризованного теста pytest.

Теперь специальные символы экранируются перед вставкой в HTML. Ошибка портила разметку отчёта и не давала удалённого выполнения кода. В выпуск также вошли семь оптимизаций производительности.

@zen_of_python

Zen of Python

14 July 2026 11:30

Hypothesis начал переносить внутренности с Python на Rust

Библиотека property-based тестирования Hypothesis в релизе 6.156.0 от 1 июля объявила о начале миграции внутренних компонентов на Rust. Пока перенесён один простой вспомогательный хелпер, но направление задано, и за неделю вышла целая серия патчей вокруг сборки — вплоть до 6.156.6 от 10 июля.

Что это значит на практике:
🔘 сборка из исходников теперь требует Rust toolchain — если ставить не из готового wheel, а компилировать, без Rust не соберётся;
🔘 чтобы это никого не сломало, проект выкатил широкий набор нативных wheels: Python с 3.10 по 3.14, free-threaded 3.14t и PyPy 3.11, под Linux x86_64/aarch64, macOS x86_64/arm64 и Windows x64;
🔘 добавили abi3-wheels на базе стабильного ABI 3.10 — один такой wheel работает на всех последующих версиях Python, включая 32-битные Linux и Windows;
🔘 отдельно собрали wheel под Pyodide (wasm32-unknown-emscripten) для запуска в браузере.

За тем же путём Python в Rust уже ушли core-части uv, ruff и pydantic. Теперь очередь дошла и до зрелой тест-библиотеки — с явным приоритетом не сломать установку тем, кто просто делает pip install.

@zen_of_python

Zen of Python

13 July 2026 20:20

Altair: графики через описание данных, а не ручная настройка каждой оси

В духе Zen of Python: простое лучше сложного. Если в Matplotlib вы сначала объявляете фигуру, потом крутите оси и legend, то в Altair вы просто говорите DataFrame, какую колонку на какую ось положить, что раскрасить и как сделать интерактивным. Библиотека сама строит визуализацию из HTML и JavaScript, которая работает в ноутбуке или сохраняется отдельным файлом.

Real Python советует ставить Altair в выделенное виртуальное окружение: вместе с ним приезжают pandas и Vega-Lite-рендерер, и лучше не мешать их с остальным окружением.

Это не замена Matplotlib. Для пиксельно точных публикационных фигур или 3D по-прежнему стоит брать Matplotlib; для интерактивного исследования в ноутбуке — Altair удобнее.

Zen of Python

13 July 2026 08:17

Репозиторий python-patterns: каталог паттернов, которые стоит выбирать с умом

В python-patterns собраны классические паттерны и идиомы Python — 42,8k звёзд, 7k форков и 896 коммитов. Сообщество использует его как шпаргалку, чтобы быстро вспомнить, как выглядит тот или иной подход в коде.

Авторы явно предупреждают: каждый паттерн несёт свои компромиссы, а выбирать нужно не по красоте реализации, а по ситуации. В Python это особенно актуально — язык сам даёт идиомы, от итераторов до менеджеров контекста, и часто проще использовать встроенное, чем городить фабрику.

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

Zen of Python

11 July 2026 10:09

Go-рутины в Python без async/await

Runloom экспериментально возвращает Python к простоте блокирующего кода: вызываете fiber(fn), пишете обычный recv/send или urlopen, а библиотека паркует задачу на сокете и переключает контекст. Никакого async def, никакого await — как до эпохи asyncio, но с миллионом лёгких потоков на всех ядрах.

Под капотом: hand-rolled ассемблерный context switch, work-stealing scheduler на C и netpoll. Цель: free-threaded Python 3.14t с выключенным GIL, когда один процесс действительно может загрузить все ядра, а не притворяться многопоточным.

Репозиторий на GitHub.

Zen of Python

10 July 2026 14:08

Метакласс: не магия, а ещё один уровень явности Python

Если класс — фабрика объектов, то метакласс играет роль фабрики самих классов. В Python 3 это не опция, а дефолт: любой ваш класс является экземпляром type, а class Foo: pass раскрывается в type('Foo', (), {}).

Свой метакласс наследуется от type и переопределяет __new__ или __init__. Он позволяет собирать, изменять или регистрировать классы программно, но в Python явность важнее изящества. В большинстве случаев ту же задачу решают наследование или декоратор класса.

Отсюда следует, почему в Python всё есть объект, включая само определение класса. Разбираемся в деталях.