Hacker News Digest

Python 3.15.0 вышел с рядом значительных улучшений: введены новые встроенные типы — sentinel и frozendict, а также по умолчанию включена UTF-8 как кодировка. Добавлена поддержка распаковки в генераторах, ленивые импорты для ускорения запуска и улучшены сообщения об ошибках. Экспериментальный JIT-компилятор показал прирост производительности до 12% на AArch64 macOS и 8% на x86-64 Linux. В стандартной библиотеке появился новый профилировщик Tachyon и отдельный пакет для инструментов профилирования. В типизации добавлены TypedDict с типизированными дополнительными полями, TypeForm для аннотаций и поддержка непересекающихся базовых типов. C-API получил новые функции, включая PyBytesWriter и защиту от некорректной финализации. На Windows теперь используется tail-calling интерпретатор, а на macOS по умолчанию включена free-threading поддержка. По умолчанию включены frame pointers для лучшей наблюдаемости на уровне системы.

Обсуждение подтверждает практическую значимость новых фич Python 3.15: стабильный ABI для free-threaded сборок сокращает CI-матрицы в 5 раз, ленивые импорты востребованы для ускорения старта, а frozendict и распаковка в компрехеншенах — долгожданные улучшения качества жизни, несмотря на медленное внедрение в дистрибутивах.

• Поддержка abi3t позволяет выпускать одну универсальную .whl-сборку для free-threaded и GIL-версий, сократив CI-матрицу с 20 до 4 джобов по опыту @hncbw02z5a.

• Ленивые импорты (PEP 810) востребованы сообществом как долгожданное улучшение для ускорения старта интерпретатора, подтверждено несколькими участниками, включая @kbumsik и @fishgoesblub.

• frozendict и распаковка в компрехеншенах (PEP 798, PEP 814) считаются долгожданными качественными улучшениями, несмотря на то, что их отсутствие было необъяснимым с 3.6 (@6gvONxR4sf7o, @tipsytoad).

• UTF-8 по умолчанию воспринимается как очевидное улучшение, но удивление участников (@hleszek) показывает, что многие не осознавали, что это ещё не было стандартом.

• Tachyon-профайлер полезен для продакшена, так как позволяет профилировать запущенные процессы без перезапуска (@febed).

• Стабильный ABI (abi3t) обеспечивает совместимость сборок на несколько версий Python вперёд, что снижает нагрузку на поддержку библиотек (@yablak, @ngoldbaum).

• Спор: Утверждение @wg0 о переходе Python-интерпретатора на Rust как основного языка опровергается @zahlman и @fastily: текущие шаги — лишь интеграция отдельных компонентов на Rust, а не замена CPython.

• Спор: Некоторые участники (@simonw, @ryandrake) критикуют политику быстрого отказа от старых версий Python, указывая, что пользователи всё ещё зависят от 3.10 и ниже, и ломать совместимость — неоправданный риск.

• Совет: Для поддержки старых систем (например, EL7) компании продолжают поддерживать Python 3.5, несмотря на EOL, что подтверждает @elevation — отсутствие поддержки ≠ отсутствие использования.

• Совет: Использование uvx --python 3.15 whatsnewt может привести к запуску альфа-версии (3.15.0a2), где некоторые фичи ещё не реализованы, как предупреждает @ameliaquining.

• Размер исходного архива Python 3.15 вырос из-за двух анимированных GIF-демонстраций Tachyon-профайлера весом >10 МБ, что вызвало критику @zahlman как неэффективное использование места.

• Совет: Для enterprise-дистрибутивов (RHEL, Ubuntu) срок поддержки Python превышает 10 лет, что делает реальное использование версий 3.8–3.14 долгосрочным, несмотря на официальный EOL (@zzzoom).

Современные инструменты, особенно LLM, радикально снизили барьер для оптимизации производительности. То, что раньше требовало экспертов в ассемблере, JIT-компиляторах или глубокой оптимизации под конкретный хардвер, теперь может сделать любой разработчик, задав правильный запрос. Пример — FRE, регулярное выражение, созданное агентом за месяц и оптимизированное под набор тестов rebar: его AOT-скомпилированная версия показала отличную производительность на длинных поисках, хотя и тратила ресурсы на компиляцию. Это открывает путь к гибридным решениям — например, запускать компилятор в фоне при работе ripgrep и переключаться на оптимизированный код, когда он готов, жертвуя скоростью для коротких запросов ради выигрыша на долгих.

Такой подход — не редкость, а новая норма. Как и JIT-компиляторы, которые раньше считались слишком сложными для внедрения, теперь их можно написать за минуты. Это позволяет создавать «сделанные на заказ» решения под конкретные рабочие нагрузки, как в демосцене или FFTW, а не универсальные библиотеки. Технологии больше не ограничивают амбиции: если раньше писали «достаточно хорошо», теперь можно добиваться максимальной скорости — даже если это требует нестандартных трюков. Производительность перестала быть привилегией элиты и стала доступной для всех.

LLM не решают проблему медленности ПО — основные причины: сетевые задержки (особенно из-за географической удаленности), архитектурные компромиссы (синхронность, буферы, изоляция ресурсов) и системные накладные расходы ОС, а не алгоритмическая неэффективность. LLM эффективны только при чётких метриках (бенчмарки, regex): например, оптимизировали SafeRE (Java) или снизили загрузку фронтенда с 4с до 750мс. Но они плохо справляются с оптимизацией памяти, кэшей, низкоуровневых механизмов и аппаратных особенностей — в обучающих данных преобладает неэффективный код, а LLM не понимают реальных ограничений, что приводит к ошибкам аллокации (например, ChatGPT на macOS потребляет до 50 ГБ). LLM работают с абстракциями, не способны к экстремальной оптимизации (демосцена, сложные движки) и не учитывают компромиссы поддержки кода, поэтому многие оптимизации (mawk 2.0, специфичные JIT) не внедряются. Эффективность зависит от качества спецификации: без чётких критериев приёмки агенты не гарантируют скорость и корректность. AI-код часто накапливает избыточные изменения, ухудшая долгосрочную производительность (парадокс Джевонса). Оптимизация стала функцией затрат: если рынок не требует скорости, ресурсы не вкладываются. Минимальный стек (node, express, ejs, pg) даёт лучшую производительность, чем перегруженные фреймворки. LLM могут формально доказывать корректность кода и снижать баги, но экономика (стоимость RAM, токенов) и аппаратные ограничения остаются главными регуляторами производительности.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

В слайдах он показал множества: «программы, где Python достаточно быстр» — подмножество «всех Python-программ», а снаружи — «все возможные программы». В идеале Python должен подходить для всех; пока что задачи, требующие максимума от процессора, не могут быть на Python. Он хочет расширять «внутренние круги».

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.