Python 3.15 меняет загрузку модулей и работу с текстом — что принесла новая версия

9 октября 2026 года вышел стабильный Python 3.15.0. Релиз добавил отложенные импорты для сокращения времени запуска программ, сделал UTF-8 кодировкой по умолчанию и расширил инструменты диагностики производительности. Разбираемся, какие изменения заметят авторы скриптов, разработчики приложений и те, кто переносит проекты с Python 3.14.

Python меняет загрузку модулей и работу с текстом

Отложенные импорты Python 3.15 сокращают работу при запуске приложения

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

В Python 3.15 появился механизм из PEP 810: разработчик может поставить слово lazy перед импортом. Модуль загрузится при первом обращении к импортированному имени. Например, этот синтаксис теперь поддерживается самим языком:

lazy import json

print("Программа запущена")
data = json.loads('{"ready": true}')

Сначала выполнится print(), а модуль json будет загружен при обращении к json.loads(). Для обычного import прежний порядок сохраняется. Это существенная оговорка: установка Python 3.15 сама по себе не делает все импорты отложенными. По умолчанию новый механизм применяется там, где его явно указал автор программы.

Подобный режим особенно интересен для CLI-инструментов с множеством команд, тестовых утилит и программ, которые загружают крупные библиотеки лишь в отдельных сценариях. Есть и цена изменения: ошибка импорта или побочный эффект при загрузке модуля теперь могут проявиться позднее — при первом использовании. Именно поэтому новая функция требует внимания к тому, как приложение и его зависимости инициализируются.

UTF-8 по умолчанию меняет чтение старых текстовых файлов

Python 3.15 реализовал PEP 686: операции чтения и записи текста без явно заданного параметра encoding теперь используют UTF-8 независимо от региональных настроек операционной системы. Раньше на некоторых системах программа могла опираться на локальную кодировку, что приводило к разному поведению одного скрипта на двух компьютерах.

Представим обмен данными между Windows и Linux. Скрипт открывает текстовый файл через open("report.txt"). Если файл сохранён в UTF-8, новая настройка делает его обработку предсказуемее. Но архивный файл в Windows-1251 может вызвать ошибку декодирования или потребовать явного указания исходной кодировки. Для такого файла в Python по-прежнему предусмотрен вариант open("report.txt", encoding="cp1251").

Разница между версиями касается именно операций без аргумента encoding. Если код уже задаёт encoding="utf-8" либо другую нужную кодировку, этот параметр продолжает определять способ чтения. В официальной документации описаны и средства сохранения прежнего поведения: переменная окружения PYTHONUTF8=0 и ключ запуска -X utf8=0.

В Python 3.15 появились неизменяемый словарь и новые возможности синтаксиса

Встроенный тип frozendict, добавленный по PEP 814, хранит пары «ключ — значение», сохраняя порядок их добавления, но запрещает менять содержимое после создания. Это удобно для неизменяемых параметров и структур данных, которые должны оставаться одинаковыми на протяжении работы программы. Объект может использоваться как хешируемое значение, если хешируемы его ключи и значения. При этом frozendict не наследуется от обычного dict: проверки через isinstance(value, dict) его не распознают.

Второй новый встроенный тип — sentinel из PEP 661. Он предназначен для специальных значений-маркеров, например когда функция должна отличать «аргумент не передали» от явно переданного None. Раньше разработчики нередко создавали для этого отдельный объект и дополнительно заботились о его отображении, типизации и сериализации.

PEP 798 расширяет генераторы коллекций и генераторные выражения: теперь они поддерживают распаковку * и **. Например, списки списков можно объединять в плоский список выражением [*part for part in groups]. До Python 3.15 для такого случая обычно использовали вложенные циклы в генераторе или инструменты из itertools. Новый синтаксис относится именно к Python 3.15 — в старых интерпретаторах его применять нельзя.

Python 3.15 ускоряет отдельные сценарии на Windows и развивает JIT

В официальных 64-битных сборках Python для Windows теперь используется интерпретатор с механизмом tail calling. Согласно измерениям разработчиков на AMD Ryzen 7 5800X, при сборке Visual Studio 2026 он показал прирост порядка 15–20% по геометрическому среднему набора тестов pyperformance по сравнению с интерпретатором на основе switch-case. Это результат конкретного тестирования, а не обещание ускорения любой программы на 20%.

Экспериментальный JIT-компилятор, который во время выполнения преобразует часть операций в машинный код, тоже получил новые оптимизации. Для сборок с включённым JIT опубликованы средние результаты: преимущество в 7–8% над стандартным интерпретатором на x86-64 Linux и 11–12% над интерпретатором с tail calling на macOS с процессором AArch64. Отдельные тесты показывают как ускорение, так и замедление, поэтому эти проценты нельзя переносить на любое приложение.

Ещё одна перемена касается поиска узких мест. В стандартной библиотеке появился пакет profiling с инструментом Tachyon (profiling.sampling). Он периодически снимает информацию о выполняемых функциях и умеет подключаться к уже работающему процессу по PID без изменения исходного кода и перезапуска приложения. Такой режим даёт возможность исследовать задержки в длительно работающих сервисах, включая время ожидания ввода-вывода и загрузку процессора. Прежний cProfile сохранён как совместимый интерфейс.

Для многопоточных сборок появился ABI abi3t, а при миграции есть несовместимости

Python 3.15 расширяет поддержку CPython без глобальной блокировки интерпретатора (free-threaded builds). Для расширений на C появился стабильный ABI abi3t, позволяющий после соответствующей адаптации создавать двоичные модули для нескольких версий свободнопоточного CPython. Авторы PEP 803 отдельно предупреждают, что переход расширений на новый интерфейс может потребовать изменений кода; прежние сборки модулей автоматически совместимыми с abi3t не становятся.

На macOS официальный установщик теперь включает поддержку free-threading по умолчанию. Это относится к доступности соответствующей сборки и не означает, что любой запускаемый скрипт автоматически начинает работать без GIL.

При переносе существующего проекта есть и более приземлённые отличия. В модуле sqlite3 у функции sqlite3.connect() все параметры, кроме имени базы данных, теперь передаются только по имени. Старый вызов с дополнительными позиционными аргументами придётся изменить. Из importlib удалён устаревший метод загрузчиков load_module(); вместо него используется exec_module(). Эти изменения особенно заметны проектам с собственными импортерами, обёртками для SQLite и зависимостями, которые используют старые API.

Отдельное предупреждение в карточке релиза связано с macOS 27.0. Приложения на tkinter, включая IDLE, могут зависать при открытии диалоговых окон через меню. Разработчики связывают это с изменением поведения macOS и указывают, что проблема затрагивает разные версии Python и Tk. Таким образом, её наличие в заметках Python 3.15 не означает, что ошибка появилась именно в новом интерпретаторе.

Какие изменения Python 3.15 останутся актуальны после релиза

Python 3.15.0 вышел как стабильная основная версия, собравшая 5 643 коммита от 1 012 участников. Отложенные импорты меняют момент загрузки зависимостей, UTF-8 по умолчанию влияет на обработку текста, а новый профилировщик упрощает исследование работающих процессов. Это изменения поведения и инструментария, которые сохранят значение и после появления очередных исправлений ветки 3.15.

Фактический выигрыш во времени запуска и скорости выполнения будет различаться между проектами. Он зависит от состава импортов, сценария работы, платформы и выбранной сборки интерпретатора. Для совместимости решающими останутся поддержка Python 3.15 сторонними библиотеками и то, какие устаревшие API ещё использует конкретный проект.