Новости
Python 3.14.8 и 3.13.16: три патча безопасности для tarfile и zipfile
Предыдущий поддерживающий релиз закрыл обходы фильтра извлечения архивов и распаковочную бомбу в zipfile.
9 октября 2026 года вышел Python 3.15. Главное изменение для тех, кто пишет скрипты для обработки файлов — реализация PEP 686: функция open() и другие операции ввода-вывода без явно указанного параметра encoding теперь используют UTF-8 вместо кодировки операционной системы. Это должно заметно снизить число «кракозябр» при переносе скриптов между Windows, Linux и macOS.

Коротко: 9 октября 2026 Python Software Foundation выпустила Python 3.15. По PEP 686 чтение и запись файлов без явного параметра encoding теперь по умолчанию идёт через UTF-8, а не через кодировку системы — главная причина «кракозябр» при переносе скриптов между Windows и Linux/macOS. Старое поведение можно вернуть флагом -X utf8=0 или переменной PYTHONUTF8=0. Также добавлены ленивые импорты (PEP 810) и встроенные типы frozendict (PEP 814) и sentinel (PEP 661).
9 октября 2026 года Python Software Foundation (PSF) выпустила Python 3.15.0 — новую основную версию интерпретатора. Релиз закрывает годовой цикл разработки: по данным новостной заметки Хабра со ссылкой на changelog, в версию вошли изменения от более чем тысячи участников сообщества. Ветка 3.15 получит полтора года полноценной поддержки с новыми функциями, а затем ещё три с половиной года — только патчи безопасности.
Из всего списка нововведений для аудитории, которая каждый день открывает, конвертирует и распаковывает файлы, важнее прочих одно изменение — новое поведение кодировки по умолчанию.
PEP 686 переводит Python на UTF-8 как кодировку по умолчанию независимо от настроек операционной системы. В официальном changelog это сформулировано прямо: «Python now uses UTF-8 as the default encoding, independent of the system's environment. This means that I/O operations without an explicit encoding, for example, open('flying-circus.txt'), will use UTF-8».
До этого изменения поведение open() без параметра encoding зависело от локали операционной системы: на англоязычной Windows чаще всего это была однобайтовая кодировка вроде cp1251 для русского текста, на Linux и macOS — обычно уже UTF-8. Именно это расхождение годами было источником проблем при переносе скриптов между платформами: один и тот же код на Windows читал текстовый файл иначе, чем на Linux.
Изменение касается только случаев, когда параметр encoding не указан явно. Если в коде уже стоит open(path, encoding='utf-8') или encoding='cp1251' — поведение не меняется. Разработчикам PSF отдельно рекомендует не полагаться на дефолт даже с учётом этого изменения: «For best compatibility between versions of Python, ensure that an explicit encoding argument is always provided».
Если скрипт раньше неявно полагался на локальную кодировку Windows при чтении файла, сохранённого в UTF-8 (или наоборот), на Python 3.15 поведение изменится. В большинстве случаев это исправит давнюю проблему автоматически — текст, который раньше открывался кракозябрами, начнёт читаться корректно. Но возможен и обратный эффект: код, который годами полагался на кодировку Windows по умолчанию для чтения локальных файлов, после обновления интерпретатора может начать выдавать UnicodeDecodeError на файлах в старых однобайтовых кодировках вроде cp1251 или windows-1252.
Для диагностики таких мест PSF оставила отдельный инструмент — «opt-in encoding warning», предупреждение, которое можно включить заранее (на более ранних версиях Python) и найти в коде все вызовы, которые неявно зависят от системной кодировки, прежде чем переходить на 3.15.
Запустите интерпретатор с флагом -X utf8=0 или задайте переменную окружения PYTHONUTF8=0 — это откатывает поведение open() к зависимости от локали ОС, как было до Python 3.15. Также можно явно указать encoding='locale' — этот параметр поддерживается ещё с Python 3.10 и использует кодировку текущей локали вне зависимости от версии интерпретатора.
Если результат открытия файла выглядит нечитаемым уже сейчас, до перехода на новую версию Python, разберитесь с правильной кодировкой вручную — в материале «Кракозябры: как исправить кодировку текстового файла» собраны рабочие способы для Windows, Excel и браузера. А определить формат файла, который не открывается нужной программой, можно инструментом определения формата по сигнатуре прямо в браузере.
PEP 810 добавляет в язык мягкое ключевое слово lazy для явно отложенных импортов: lazy import json или lazy from pathlib import Path. Такой модуль физически не загружается в момент запуска скрипта — загрузка откладывается до первого реального обращения к имени. Это сохраняет привычный стиль, когда все импорты перечислены в начале файла, но убирает цену загрузки тех модулей, которые в конкретном запуске программы так и не понадобились.
Управлять этим можно и глобально — переменной окружения PYTHON_LAZY_IMPORTS, флагом -X lazy_imports или через новые функции sys.set_lazy_imports() и sys.set_lazy_imports_filter() с собственным фильтром, какие именно импорты делать ленивыми. Ограничение: ленивым можно сделать только импорт на уровне модуля — внутри функции, класса или блока try/except конструкция lazy import вызовет SyntaxError.
Python 3.15 добавляет в builtins неизменяемый словарь frozendict (PEP 814) — объект нельзя изменить после создания, он хэшируем, если хэшируемы все его ключи и значения, и сохраняет порядок вставки. В стандартной библиотеке его уже умеют обрабатывать модули copy, json, pickle, marshal, pprint и xml.etree.ElementTree — то есть сериализация и работа с конфигурациями или ответами API через frozendict не требует дополнительных обёрток.
Второе добавление — встроенный тип sentinel (PEP 661) для создания уникальных «дозорных» значений с понятным выводом в консоли, вместо распространённого в коде паттерна _SENTINEL = object(), у которого нет осмысленного представления при отладке.
Если вы администрируете сервер или пишете скрипты, которые регулярно открывают текстовые файлы, CSV или конфиги без явного указания кодировки, — после перехода на Python 3.15 стоит проверить эти места в первую очередь. Для работы с табличными данными это особенно актуально: при открытии больших выгрузок разница в кодировке между системами видна сразу, разобраться с форматом и кодировкой CSV-файла помогает отдельный гайд Loadfile.
Прежде чем обновлять продакшен-окружение, PSF рекомендует сначала включить encoding warning на текущей версии интерпретатора, найти неявные места и явно проставить нужную кодировку — а уже потом переходить на 3.15, чтобы поведение кода не зависело от версии Python, на которой он запущен.