Python 3.15 вышел в четверг, 1 октября 2026 года. Изменение, которое с наибольшей вероятностью повлияет на существующий код, — это новая кодировка по умолчанию: текстовый ввод-вывод теперь использует UTF-8 независимо от системной локали, поэтому код, открывающий файлы без явного аргумента encoding=, может считывать их иначе, особенно в Windows. В этом релизе также добавлено ключевое слово lazy, которое откладывает «тяжелые» импорты до момента их первого использования, что ускоряет запуск ноутбуков и инструментов командной строки, а также профилировщик выборки в стандартной библиотеке, который подключается к работающему процессу без его перезапуска или добавления инструментов. Если ваш код открывает файлы без указания кодировки, проверьте его перед обновлением.

Как сопровождающие основных каналов Anaconda (main и main-x), мы прорабатываем, что новый интерпретатор означает для тысяч пакетов. Узнайте больше об Anaconda main-x. Вот что, по нашему мнению, важно в этом релизе.

Переход на Python 3.15 зависит от готовности пакетов и платформ, на которые полагаются разработчики. Наше сотрудничество с Microsoft и Qualcomm позволит помочь разработчикам создавать приложения с использованием нативных пакетов Python на современном оборудовании.

«Перенос Windows Arm64 в мейнстрим разработки на Python требует большего, чем просто нативная среда выполнения. Нужна сильная экосистема пакетов. Anaconda стала важным партнером в этой работе, предоставив тысячи нативных пакетов для Windows Arm64 и упростив разработчикам создание, тестирование и развертывание с уверенностью». — Крис Андерсон, заслуженный инженер, Windows Platform + Developer

Это сотрудничество также связывает экосистему пакетов Python с оборудованием, которое используют разработчики, включая устройства на базе Windows с процессорами Snapdragon.

«Разработчики процветают, когда их инструменты просто работают, поэтому сильная и всесторонняя экосистема Python так важна для платформ Snapdragon серии X. Тесно сотрудничая с Microsoft, Anaconda и партнерами по экосистеме, мы продолжаем развивать нативную поддержку во всем стеке Python, упрощая разработчикам создание, тестирование и развертывание приложений на Windows on Snapdragon. Это дополнительно позволяет разработчикам использовать преимущества превосходной производительности, энергоэффективности и возможностей ИИ устройств на базе Windows с процессорами Snapdragon». — Милан Плавшич, вице-президент по инжинирингу, Qualcomm Technologies, Inc.

Что меняется и что с этим делать

(PEP — это Python Enhancement Proposal, механизм, с помощью которого язык получает новые функции. PEP 8, руководство по стилю, — это то, с чем большинство людей сталкивается в первую очередь.)

Пять изменений, важных для работы с данными

1. UTF-8 теперь является кодировкой по умолчанию (PEP 686)

Это изменение с самым широким радиусом поражения. Раньше при открытии файла без явного указания кодировки использовалась системная локаль, поэтому один и тот же скрипт мог считывать один и тот же файл по-разному на Linux-раннере CI и на ноутбуке коллеги с Windows. В версии 3.15 текстовый ввод-вывод по умолчанию использует UTF-8 независимо от окружения.

Стоит знать, чего это касается. Затронуто все, что проходит через обычный open(), включая pathlib, csv и numpy.loadtxt. Исключение составляет pandas: read_csv уже по умолчанию использует UTF-8, поэтому он ведет себя одинаково как до, так и после 3.15.

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

Проведите аудит кодовой базы перед обновлением:

Каждое предупреждение отмечает операцию с файлом, результат которой зависит от локали, в которой она выполняется. Именно этот код версия 3.15 делает детерминированным. Добавление явных аргументов encoding= безопасно в любой версии Python, которую вы сейчас поддерживаете, поэтому вы можете сделать это сегодня, еще до обновления чего-либо. Это самое ценное действие в этой статье. Если вам тем временем нужно старое поведение, PYTHONUTF8=0 восстанавливает кодировку на основе локали глобально, а encoding="locale" делает это для каждого вызова.

2. Явные ленивые импорты (PEP 810)

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

Python 3.15 добавляет «ленивое» (lazy) мягкое ключевое слово, которое откладывает работу до момента первого использования имени:

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

Одно предостережение, прежде чем вы начнете это использовать. lazy откладывает побочные эффекты модуля во время импорта вместе с самим импортом, поэтому все, что регистрирует бэкенд, плагин или кодек при загрузке, должно использовать обычный импорт. Модуль, импортированный исключительно ради побочного эффекта, где связанное имя никогда не используется, не загрузится вовсе.

lazy работает только на уровне модуля и не работает с импортами типа star или __future__. Чтобы включить его без редактирования исходного кода, и -X lazy_imports, и PYTHON_LAZY_IMPORTS принимают значение: all делает каждый импорт ленивым, normal — это значение по умолчанию, которое учитывает ключевое слово. Так что это -X lazy_imports=all, а не просто флаг. Код, который также должен работать на 3.14, может объявить __lazy_modules__.

3. Профилировщик выборки промышленного уровня (PEP 799)

Инструменты профилирования Python теперь живут в одном пакете profiling: profiling.tracing для детерминированного трассирования вызовов (перенесен из cProfile) и profiling.sampling — новый статистический профилировщик выборки под названием Tachyon.

Детерминированные профилировщики инструментируют каждый вызов, что замедляет программу и искажает измерения. Tachyon вместо этого берет выборки стеков вызовов из работающего процесса. В примечаниях к выпуску говорится, что он имеет практически нулевые накладные расходы и достигает частоты выборки до 1 000 000 Гц. Вы можете подключиться к уже запущенному заданию обучения по идентификатору процесса (PID), не перезапуская его и не добавляя ни строчки инструментов:

Подключение считывает память целевого процесса, поэтому в большинстве систем требуются повышенные привилегии. Системные требования описывают, что запрашивает каждая ОС.

Четыре режима охватывают вопросы, которые действительно задают команды по работе с данными:

Третья строка заслуживает особого внимания. Перед инвестированием в миграцию на свободную потоковую модель (free-threading), --mode gil подскажет, является ли конкуренция за блокировки вашим «узким местом».

Вывод может быть в виде таблиц pstats, графов пламени (flame graphs), тепловой карты на уровне строк, формата Gecko для Firefox Profiler или живого терминального представления в стиле top. cProfile остается как псевдоним; старый модуль profile объявлен устаревшим и будет удален в 3.17.

4. Стабильный ABI для сборок со свободной потоковой моделью (PEP 803)

В Python 3.14 режим свободной потоковой модели (free-threaded) стал официально поддерживаемым. C-расширения, нацеленные на стабильный интерфейс двоичного уровня (ABI), не имели цели, совместимой со свободной потоковой моделью, поэтому для каждого пакета требовалась отдельная сборка для каждой версии Python.

Python 3.15 представляет abi3t, стабильный ABI для сборок со свободной потоковой моделью. Расширения, скомпилированные с его использованием, работают с CPython со свободной потоковой моделью без пересборки под каждую версию, что делает широкое покрытие колес (wheels) устойчивым, а не героическим.

Учтите два важных нюанса. Переход на abi3t — это не просто перекомпиляция: он требует внесения изменений в исходный код, включая использование API PEP 697 из версии 3.12 и нового хука экспорта PyModExport_* из PEP 793. Кроме того, на момент выпуска версии 3.15 основные системы сборки еще не поддерживали его, поэтому проверьте свои инструменты, прежде чем делать выводы, и пока продолжайте компилировать cp315t отдельно. CPython предоставляет руководство для разработчиков, готовых начать.

В Anaconda мы уже сегодня поставляем вариант интерпретатора с отключенной глобальной блокировкой (free-threaded), и мы работаем над тем, чтобы распространить такие сборки за пределы интерпретатора на пакеты, начиная с Python 3.14 и продолжая в 3.15, без фиксированных дат завершения.

5. Файлы конфигурации запуска заменяют строки импорта в .pth (PEP 829)

Файлы .pth, загружаемые модулем site при запуске, могут расширять sys.path, а также выполнять произвольный код, если строка начинается с import. Это второе поведение широко распространено: setuptools поставляет distutils-precedence.pth, и некоторые редактируемые установки делают то же самое. Это трудно проверить, потому что ничто не сообщает вам, что именно выполняется при запуске интерпретатора.

Python 3.15 представляет файлы .start, содержащие спецификации точек входа в формате pkg.mod:callable. Вы можете прочитать такой файл и точно знать, что он вызывает. Из этого следуют два вывода:

Строки import в файлах .pth негласно считаются устаревшими, без каких-либо предупреждений. Строки расширения путей это не затрагивает.
Когда существует соответствующий файл .start, строки import в соответствующем файле .pth игнорируются.

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

Также стоит знать

Инкрементальный сборщик мусора был отменен. Python версий с 3.14.0 по 3.14.4 включал его; после сообщений о значительной нагрузке на память в производственных средах он был заменен на поколенческий сборщик из версии 3.13. Именно этот сборщик используется в версии 3.14.5 и более поздних, а также в 3.15. Если вы наблюдали необъяснимый рост потребления памяти в ранних версиях 3.14, скорее всего, причина в этом.
JIT-компилятор был значительно улучшен: добавлен новый фронтенд трассировки, базовая аллокация регистров и улучшенная генерация машинного кода. Он все еще является экспериментальным и по-прежнему отключен по умолчанию, но теперь он компилируется в официальные сборки, а не отсутствует в них.
Распаковка в генераторах списков (PEP 798), поэтому [*batch for batch in batches] заменяет itertools.chain.from_iterable() для выравнивания списков.
Встроенные типы frozendict и sentinel (PEP 814, PEP 661). Обратите внимание, что frozendict не является подклассом dict, поэтому проверки isinstance(x, dict) необходимо обновить до isinstance(x, (dict, frozendict)).
Изменены комплексные типы ctypes. Типы _type_ для c_float_complex, c_double_complex и c_longdouble_complex были изменены с F, D и G на Zf, Zd и Zg для совместимости с NumPy.
Указатели кадров (frame pointers) включены по умолчанию (PEP 831), плюс улучшенные подсказки для AttributeError и поддержка цветов в интерфейсах командной строки (CLI) стандартной библиотеки.
Дальнейшие удаления. Помимо указанных в таблице выше: ctypes.SetPointerType, glob.glob0 и glob.glob1, pathlib.PurePath.is_reserved, platform.java_ver и создание TypedDict с нулевым количеством полей. typing.ByteString и collections.abc.ByteString покидают __all__ своих модулей перед полным удалением в версии 3.17. Полный список доступен в примечаниях к выпуску.

Когда переходить

Завершение поддержки Python 3.10

Anaconda прекращает поддержку Python 3.10 в конце октября 2026 года, что соответствует пятилетнему циклу поддержки Python Software Foundation (PSF). После этой даты интерпретатор 3.10 и соответствующие пакеты останутся доступными в основном канале, но ни PSF, ни Anaconda не будут выпускать исправления или обновления безопасности, и мы перестанем собирать новые пакеты для 3.10.

Окружение 3.10 продолжит работать. Оно просто перестанет получать исправления безопасности, в то время как окружающая экосистема будет двигаться дальше. Подробности приведены в нашей политике поддержки версий Python.

Начало работы

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

Наша политика поддержки определяет ожидаемый график, поэтому вы можете планировать работу, а не гадать: как только PSF выпускает официальный релиз, мы обычно публикуем интерпретатор в основном канале в течение двух недель, первые пакеты — в течение месяца, а большинство оставшихся пакетов — в течение четырех месяцев. Мы ожидаем, что Python 3.15 будет следовать этому шаблону.

Если вы поддерживаете пакеты, добавьте 3.15 в свою матрицу CI и поддерживайте актуальность своих рецептов conda-forge. Один нюанс, который легко упустить: если ваша система сборки компилирует C, C++ или Rust, не наследуя флаги sysconfig Python, включите флаги указателей кадров (frame-pointer) самостоятельно, так как один компонент, собранный без них, нарушает размотку стека для всего процесса.

Загрузите Anaconda Distribution или Miniconda для настройки тестовых окружений.

Есть вопросы о совместимости с Python 3.15? Обратитесь в нашу службу поддержки или начните обсуждение на наших форумах сообщества.