Zen of Python

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

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

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

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

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

В 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

Донхи На и Никита Соболев предложили 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

Видеофайл на 50 КБ может выполнить код на вашем устройстве В FFmpeg нашли 16-летнюю уязвимость PixelSmash. Она живёт в декодере MagicYUV: AVI, MKV или MOV размером с картинку вызывает запись за пределами буфера и открывает удалённое выполнение кода. Серьёзность: 8.8 из 10 по шкале CVSS, то есть «высокая». MagicYUV включён везде по умолчанию «для вашего удобства». Поэтому плееры, мессенджеры, NAS и облачные транскодеры принимают вредоносное видео без вопросов, лишь бы система сгенерировала превью. Проверьте себя командой из материала: если в выводе есть magicyuv, обновите FFmpeg или пересоберите с флагом --disable-decoder=magicyuv. За 16 лет она успела разойтись повсюду.

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

Как в 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

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

Разбор 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

Сервис убивало по нехватке памяти каждые несколько часов, но утечки в нём не было 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

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

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

Шесть проверщиков типов для 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

Многопоточный NumPy на сборке без GIL был в 7 раз медленнее процессов, стал в 4 раза быстрее Всё началось с вопроса на Stack Overflow: пользователь пожаловался, что на сборке CPython без GIL расчёт через ThreadPoolExecutor заметно медленнее того же расчёта через ProcessPoolExecutor. Кумар Адитья из Quansight Labs описал 29 июля, как несколько месяцев вычищал причины этого в NumPy и самом CPython. Нагрузка простая и типичная для ufunc: каждый работник берёт свой массив, гоняет по нему np.sin и np.cos в цикле и сворачивает результат. Общего изменяемого состояния между потоками нет, так что масштабироваться оно должно линейно. На деле до 18 потоков росло, а дальше резко деградировало: на 32 работниках 44 секунды против 6 у процессов. Профилирование через samply показало три класса проблем: конкуренция за блокировки, конкуренция за счётчики ссылок общих объектов и конкуренция в аллокаторе. 🔘 tracemalloc выключен по умолчанию, но всё равно брал глобальную блокировку на каждом выделении и освобождении памяти, просто чтобы проверить, включён ли он. Теперь проверка идёт атомарной операцией без блокировки; 🔘 кэш диспетчеризации ufunc, который сопоставляет типам аргументов конкретную реализацию, жил под std::shared_mutex. Записи в нём неизменяемы, поэтому чтение сделали полностью свободным от блокировок, мьютекс остался только на редкие вставки; 🔘 указатель на аллокатор памяти NumPy хранит в глобальном объекте PyCapsule. Без GIL каждое обращение к нему меняет счётчик ссылок атомарно, и кэш-линия со счётчиком начинает метаться между ядрами. Объект сделали бессмертным, то есть вообще без подсчёта ссылок; 🔘 ради этого в CPython появился публичный PyUnstable_SetImmortal: с 3.15 он доступен всем, на 3.14 его можно взять через pythoncapi-compat; 🔘 запись np.sin — это поиск атрибута в модуле, а специализация байткода для таких поисков не работала, если модуль определяет __getattr__. Каждый вызов уходил на медленный путь с захватом импортной блокировки; 🔘 массивы NumPy выделял системным malloc, который плохо переносит параллельные выделения, особенно на macOS. Сырой аллокатор CPython в сборке без GIL перевели на mimalloc, а NumPy переключили на этот сырой аллокатор. После всех правок та же задача на 32 ядрах занимает около 1,5 секунды: примерно в 30 раз быстрее, чем было, и вчетверо быстрее варианта с процессами. Автор оговаривает, что замеры сделаны на одной 32-ядерной машине с Linux и на конкретной ufunc-нагрузке без общего состояния между потоками. Полная статья: https://labs.quansight.org/blog/scaling-numpy-on-free-threaded-python @zen_of_python

На маленьком проекте подмена времени стоит 1406,7 микросекунды против 1,5, на большом — 40 971,3 против тех же 1,5 Адам Джонсон, автор time-machine, замерил 3 августа, как две библиотеки подмены текущего времени ведут себя с ростом проекта. Прошлый такой замер он делал в 2021 году и получил разницу в 100–200 раз, теперь захотел показать не отношение, а саму зависимость от размера кодовой базы. Стенд простой: генерируются пустые модули по 25 атрибутов, каждый десятый держит ссылки на date, datetime и time, как будто их импортировали по имени. Замеряется цикл включения и выключения подмены. Python 3.15, MacBook на M1, freezegun 1.5.5 и time-machine 3.3.0. 🔘 259 модулей, то есть почти голый интерпретатор: 1406,7 мкс против 1,5 мкс, разница в 940 раз; 🔘 1259 модулей, размер небольшого проекта на Django: разница в 2490 раз; 🔘 16 259 модулей, крупный проект с обвесом зависимостей: 40 971,3 мкс против неизменных 1,5 мкс, разница в 27 300 раз; 🔘 время freezegun укладывается в прямую: около 1,4 мс постоянных расходов плюс 2,5 мкс на каждый модуль; 🔘 в наборе из 2000 тестов с подменой времени это 82 секунды чистой замены ссылок против 3 миллисекунд; 🔘 причина в том, что freeze_time.start() обходит весь sys.modules и подменяет каждую найденную ссылку на настоящие функции; даже при попадании в кэш приходится перечислить и захешировать имена атрибутов всех модулей. У обхода есть и содержательная плата, помимо скорости: он не находит ссылки в атрибутах классов, значениях по умолчанию, замыканиях и C-расширениях, и они продолжают отдавать настоящее время. Плюс подставленные объекты видны по типу, datetime.__name__ внутри подмены становится FakeDatetime, и код, который смотрит на типы, может повести себя иначе. time-machine вместо обхода переписывает указатель ml_meth в структуре PyMethodDef у встроенных функций, читающих часы. Таких функций десять, и это ровно десять записей в память независимо от размера проекта. Автор оговаривает, что модули в стенде синтетические, это types.ModuleType, положенные прямо в sys.modules, а не настоящие импорты, и что замеряется только цикл подмены, из нескольких прогонов берётся минимальное время. Полная статья: https://adamj.eu/tech/2026/08/03/python-time-machine-o1-freezegun-on/ @zen_of_python

Бинарный поиск ускорили в 8 раз, не меняя ни алгоритм, ни язык: 16,6 процента промахов предсказателя ветвлений превратились в ноль Итамар Тёрнер-Трауринг разобрал шаг из градиентного бустинга в scikit-learn: миллион чисел с плавающей точкой нужно разложить по 255 корзинам, для чего по массиву границ гоняется бинарный поиск. Код уже скомпилированный и уже параллелится по ядрам, алгоритм оптимальный. Статья опубликована 11 июля и обновлена 18-го, работа сделана в рамках Quansight. Остался запас, который не виден на уровне алгоритма. Современное ядро процессора выполняет несколько инструкций одновременно и угадывает, куда пойдёт ветвление. В бинарном поиске сравнение по определению непредсказуемо: каждая итерация с равной вероятностью идёт влево или вправо, и предсказатель ошибается примерно в половине случаев, а конвейер каждый раз сбрасывается. 🔘 исходная версия: 45 200,4 микросекунды, 16,6 процента неверных предсказаний, 0,7 инструкции за такт, около 27 инструкций ветвления на одно значение; 🔘 первая переделка убирает ветвление, заменяя его условным присваиванием через select_unpredictable: 9 685,2 мкс, промахов ноль, 3,2 инструкции за такт, ветвлений 19 на значение; 🔘 предвычисление половины диапазона и доступ без проверки границ дают 7 280,4 мкс и обрушивают число инструкций ветвления до 6 020 571 на весь прогон; 🔘 финальная версия обрабатывает значения кусками по 16 штук с внешним циклом по шагам поиска: 5 453,4 мкс и 4,9 инструкции за такт; 🔘 любопытно, что она выполняет больше инструкций, чем предыдущая, но идёт быстрее: независимые куски работы позволяют процессору выполнять их одновременно; 🔘 итог — примерно восьмикратное ускорение на том же алгоритме, том же языке и одном ядре. Автор оговаривает, что это упрощённый пример, а не полная реализация из scikit-learn, и что статья не заменяет учебник по устройству процессора. В обновлении он честно пишет, что раньше ошибся со сравнением чисел с плавающей точкой, и после исправления SIMD перестал давать выигрыш, хотя код от этого стал только быстрее. Дальнейший запас автор видит в параллелизме по ядрам. Польза для питониста прямая: когда расчёт уже переписан на расширение и всё равно кажется медленным, следующий уровень — не алгоритм, а поведение процессора на этом коде. Полная статья: https://pythonspeed.com/articles/branchless-binary-search/ @zen_of_python

Проверка одной группы объектов стоит времени, пропорционального размеру группы, а полный проход сборщика — всему содержимому процесса 28 июля на discuss.python.org появилось предложение научить сборщик мусора принимать подсказки: разработчик или анализатор кода говорит, что вот эта группа объектов, скорее всего, больше никому не нужна, а сборщик проверяет и освобождает её, не запуская полный обход поколения. Смысл в том, как в CPython устроено освобождение памяти. Основную работу делает подсчёт ссылок, он мгновенный и точный. Но объекты, ссылающиеся друг на друга по кругу, счётчиками не убираются: у запроса лежит ссылка на его статус, у статуса обратная ссылка на запрос, оба недостижимы снаружи, а счётчики у обоих равны единице. За такие случаи отвечает отдельный сборщик циклов, и он останавливает все потоки, чтобы обойти память. 🔘 предлагаемая проверка простая: просуммировать счётчики ссылок объектов группы и посчитать, сколько ссылок на них идёт изнутри самой группы. Совпало — снаружи на группу никто не смотрит, можно освобождать; 🔘 в примере с запросом и статусом обе суммы равны двум, поэтому пара удаляется без обхода кучи; 🔘 подсказка ничего не гарантирует и всегда проверяется, а если из какой-то категории приходит слишком много ложных подсказок, её можно перестать слушать; 🔘 автор ссылается на известный случай Instagram, где сборщик отключали и просто перезапускали машины по мере роста памяти, и на статистику, по которой сборка мусора съедает от 5 до 30 процентов процессорного времени; 🔘 в обсуждении сразу возразили: Терри Ридди спрашивает, насколько часто цикл нельзя просто разорвать руками, а Грег Юинг — есть ли алгоритм, который окажется дешевле честной сборки; 🔘 ещё одно возражение практическое: подсказки придётся обновлять при каждой правке структур данных и как-то проверять тестами, а если уж писать такой тест, проще искать сами циклы и разрывать их. Замеров у автора нет, работающего кода тоже: это предложение и спор вокруг него. Но читать его полезно из-за самого разбора механики: видно, что подсчёт ссылок и сборщик циклов решают разные задачи, и что цена второго определяется размером всей кучи, а не количеством мусора. Обсуждение: https://discuss.python.org/t/improving-python-garbage-collection-performance-by-providing-unreachable-cycles-hints/108307 @zen_of_python