Виктор Стиннер, один из ключевых разработчиков CPython, разобрал в блоге, как устроен PyMutex, замок размером в один байт, на котором держится free-threaded Python.

Зачем такой маленький? В режиме без GIL блокировка нужна на каждый объект отдельно: свой замок у каждого dict, list, set. Старый замок через py_recursivelock_t занимает 72 байта. Для сравнения, пустой список в Python 3.13 весит 56 байт, пустой словарь 64. Вешать по 72 байта на каждый объект невозможно. PyMutex решает это: один байт, из которого реально используются два бита под состояния (свободен, занят, занят с ожидающими потоками).

Что показали замеры. Дизайн взят из WebKit, у их движка есть WTF::Lock, а под капотом лежит _PyParkingLot, кроссплатформенный аналог futex. На захвате и освобождении без конкуренции:
🔘Linux x86-64: PyMutex 11 нс против 44 нс у старого замка, в 4 раза быстрее;
🔘macOS arm64: 13 нс против 18 нс, в 1,4 раза;
🔘Windows x86-64: 13 нс против 38 нс, в 2,9 раза.

Оговорка для авторов C-расширений: напрямую PyMutex использовать не стоит, легко словить взаимоблокировку. Для защиты доступа к объектам есть critical section API, Py_BEGIN_CRITICAL_SECTION(obj).

@zen_of_python

Pathway — Python-фреймворк для потоковой обработки данных на Rust-движке

Pathway даёт писать на Python пайплайны реального времени: чтение из источника, преобразования, запись в приёмник, а тяжёлая часть считается Rust-движком. Тот же код работает и на пакетных данных, и на бесконечном потоке. Релиз v0.31.1 вышел 12 июня, на GitHub больше 62 тысяч звёзд.

Этот релиз почти целиком про новые коннекторы к базам:
🔘pw.io.elasticsearch.read читает индекс Elasticsearch: своего механизма отслеживания изменений у него нет, поэтому коннектор опрашивает и сверяет пересечение соседних запросов, чтобы ни одна строка не потерялась и не пришла дважды;
🔘pw.io.clickhouse.write пишет в ClickHouse по нативному протоколу, в двух режимах: поток изменений с колонками time и diff либо снапшот текущего состояния в ReplacingMergeTree;
🔘pw.io.mysql.read делает полноценный захват изменений через бинлог MySQL: сначала снимок таблицы, потом непрерывная доставка вставок, обновлений и удалений;
🔘расширили чтение Iceberg, теперь декодируются все примитивные типы, включая date, time, uuid, fixed и decimal;
🔘у коннекторов Postgres добавили набор проверок на старте, чтобы кривая конфигурация падала понятной ошибкой ещё до молчаливой потери строк.

Пригодится дата-инженерам, которые строят аналитику и ETL реального времени и устали склеивать поток из десятка разных коннекторов вручную.

https://github.com/pathwaycom/pathway

Язык: Python и Rust. Лицензия: BSL-1.1.

@prog_tools

Вышла CPython 3.15.0b3 — предпоследняя бета перед заморозкой

23 июня вышла третья из четырёх бета-версий Python 3.15: около 195 правок от 86 контрибьюторов со времён второй беты. Набор фич уже заморожен, дальше только багфиксы и шлифовка. Release candidate назначен на 4 августа, финальный релиз на 1 октября, и команда просит прогнать свой код на бете, чтобы поймать регрессии и поломки ABI заранее.

Что приедет в серии 3.15 по сравнению с 3.14:
🔘PEP 686: UTF-8 становится кодировкой по умолчанию, открытие файлов без явного encoding больше не зависит от локали системы;
🔘PEP 810: явные ленивые импорты, модуль грузится при первом обращении, а не на старте программы, это срезает время запуска тяжёлых утилит;
🔘PEP 814: встроенный тип frozendict, неизменяемый словарь без сторонних библиотек;
🔘PEP 661: встроенный sentinel для значений-маркеров вместо самодельных объектов-заглушек;
🔘PEP 798: распаковка через * и ** прямо внутри list- и dict-comprehension;
🔘PEP 799: отдельный пакет для профилирования и Tachyon, высокочастотный статистический сэмплер.

@zen_of_python

uv 0.11.26 — резолвер зависимостей ускорили сразу с четырёх сторон

uv — быстрый пакетный менеджер и резолвер зависимостей для Python на Rust, замена pip и pip-tools в одном бинарнике. Версия 0.11.26 вышла 30 июня и целиком посвящена скорости резолвинга.

Что ускорили:
🔘 зависимости в PubGrub теперь передаются как ID вместо полных структур, это снижает накладные расходы на каждой итерации резолвера;
🔘 убрали лишние аллокации в ForkMap::contains, структуре, которая проверяет пересечения версий между форками резолвера;
🔘 резолвер стал переиспользовать уже проделанную работу между итерациями PubGrub вместо пересчёта с нуля;
🔘 ускорили выбор кандидата версии для непересекающихся диапазонов зависимостей.

Заодно поправили мелочь: uv теперь предупреждает, если build cache случайно оказался внутри директории с исходниками проекта.

Резолвер зависимостей редко попадает в заголовки, но именно на нём держится ощущение «uv install мгновенный». Вы уже увидели разницу в скорости на своих проектах, или для небольших requirements.txt она и так была незаметна?

@zen_of_python

У Python появится отдельный совет по паковке — назначили даты первых выборов

После того как Steering Council в апреле утвердил PEP 772, PSF объявила даты первых выборов в новый Python Packaging Council: технический орган, который берёт на себя решения по спецификациям совместимости пакетов.

Совет состоит из пяти мест: два кандидата с наибольшим числом голосов получают двухлетний срок, а три оставшихся получают годовой. Голосование пройдёт параллельно с выборами PSF Board 2026.

Даты, если планируете участвовать:
🔘 28 июля: открытие номинаций;
🔘 11 августа: закрытие номинаций;
🔘 13 августа: публикация списка кандидатов;
🔘 25 августа: дедлайн подтверждения намерения голосовать;
🔘 1–15 сентября: само голосование.

Голосовать смогут члены PSF уровня Contributing, Supporting или Fellow, которые заранее подтвердят намерение участвовать.

Управление пакетным хозяйством Python годами было разбросано между pip, PyPA, отдельными PEP и добровольцами-энтузиастами. Кажется ли вам, что выделенный совет реально наведёт порядок, или это ещё один орган для лишних согласований?

@zen_of_python