Что нового в Python 3.13 — документация Python 3.13.0

Лучший интерактивный переводчик

Python теперь использует новый интерактивный оболочка по умолчанию, основанная на коде из Проект PyPy. Когда пользователь запускает РЕПЛ из интерактивного терминала теперь поддерживаются следующие новые функции:

• Многострочное редактирование с сохранением истории.

• Прямая поддержка специфичных для REPL команд, таких как помощь, Выходи покидатьбез необходимости вызывать их как функции.

• Подсказки и обратные связи с цвет включен по умолчанию.

• Интерактивный просмотр справки с помощью Ф1 с отдельной историей команд.

• Просмотр истории с помощью Ф2 который пропускает вывод, а также
  >>> и … подсказывает.

• «Режим вставки» с F3 это упрощает вставку больших блоков кода (нажмите F3 еще раз, чтобы вернуться к обычному приглашению).

Чтобы отключить новую интерактивную оболочку, установите PYTHON_BASIC_REPL переменная среды. Подробнее об интерактивном режиме см. Интерактивный режим.

(Представлено Пабло Галиндо Сальгадо, Лукашом Лангой и Лисандросом Николау в gh-111201 на основе кода из проекта PyPy. Поддержка Windows предоставлена Дино Виландом и Энтони Шоу.)

Улучшенные сообщения об ошибках

• Распространенной ошибкой является написание скрипта с тем же именем, что и у модуля стандартной библиотеки. Если это приводит к ошибкам, теперь мы отображаем более полезное сообщение об ошибке:

  $ python random.py
  Traceback (most recent call last):
    File "/home/me/random.py", line 1, in 
      import random
    File "/home/me/random.py", line 3, in 
      print(random.randint(5))
            ^^^^^^^^^^^^^^
  AttributeError: module 'random' has no attribute 'randint' (consider renaming '/home/me/random.py' since it has the same name as the standard library module named 'random' and the import system gives it precedence)
  

  Аналогично, если скрипт имеет то же имя, что и сторонний модуль, который он пытается импортировать, и это приводит к ошибкам, мы также отображаем более полезное сообщение об ошибке:

  $ python numpy.py
  Traceback (most recent call last):
    File "/home/me/numpy.py", line 1, in 
      import numpy as np
    File "/home/me/numpy.py", line 3, in 
      np.array([1, 2, 3])
      ^^^^^^^^
  AttributeError: module 'numpy' has no attribute 'array' (consider renaming '/home/me/numpy.py' if it has the same name as a third-party module you intended to import)
  

  (Предоставлено Шантану Джайн в gh-95754.)

• Сообщение об ошибке теперь пытается предложить правильный аргумент ключевого слова, когда в функцию передается неправильный аргумент ключевого слова.

  >>> "Better error messages!".split(max_split=1)
  Traceback (most recent call last):
    File "", line 1, in 
      "Better error messages!".split(max_split=1)
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  TypeError: split() got an unexpected keyword argument 'max_split'. Did you mean 'maxsplit'?
  

  (Предоставлено Пабло Галиндо Сальгадо и Шантану Джайн в gh-107944.)

Свободнопоточный CPython

CPython теперь имеет экспериментальную поддержку работы в режиме со свободным потоком, с глобальная блокировка интерпретатора (GIL) отключен. Это экспериментальная функция, поэтому по умолчанию она не включена. Для режима со свободной резьбой требуется другой исполняемый файл, обычно называемый python3.13t или python3.13t.exe. Предварительно созданные двоичные файлы, помеченные как со свободной резьбой можно установить как часть официального Окна

и macOS установщики, или CPython можно собрать из исходного кода с помощью --disable-gil вариант.

Выполнение без потоков позволяет полностью использовать доступную вычислительную мощность за счет параллельного выполнения потоков на доступных ядрах ЦП. Хотя не все программное обеспечение получит от этого выгоду автоматически, программы, разработанные с учетом многопоточности, будут работать быстрее на многоядерном оборудовании.
Режим со свободной резьбой является экспериментальным. и работа над его улучшением продолжается: ожидайте некоторых ошибок и существенного снижения однопоточной производительности. Свободнопоточные сборки CPython поддерживают возможность запуска с включенным GIL во время выполнения с использованием переменной среды. PYTHON_GIL или параметр командной строки -X gil=1.

Чтобы проверить, поддерживает ли текущий интерпретатор свободную поточность, python -VV

и sys.version содержат «экспериментальную сборку со свободной многопоточностью». Новый sys._is_gil_enabled() Функцию можно использовать для проверки того, действительно ли GIL отключен в запущенном процессе.

Модули расширения C-API необходимо создавать специально для сборки со свободным потоком. Расширения, поддерживающие работу с ГИЛ инвалидам следует использовать Py_mod_gil слот. Расширения, использующие однофазную инициализацию, должны использовать PyUnstable_Module_SetGIL() чтобы указать, поддерживают ли они работу с отключенным GIL. Импорт расширений C, которые не используют эти механизмы, приведет к включению GIL, если только GIL не был явно отключен с помощью PYTHON_GIL переменная среды или
-X gil=0 вариант. Для установки пакетов с расширениями C в сборке со свободным потоком требуется pip 24.1 или новее.

Эта работа стала возможной благодаря многим людям и организациям, в том числе большому сообществу участников Python и сторонним проектам по тестированию и обеспечению поддержки свободной многопоточности. Среди известных авторов: Сэм Гросс, Кен Джин, Донхи На, Итамар Орен, Мэтт Пейдж, Бретт Симмерс, Дино Виланд, Карл Мейер, Натан Голдбаум, Ральф Гоммерс, Лисандрос Николау и многие другие. Многие из этих участников работают в компании Meta, которая предоставила значительные инженерные ресурсы для поддержки этого проекта.

Экспериментальный JIT-компилятор

Когда CPython настроен и собран с использованием --enable-experimental-jit В качестве опции добавляется JIT-компилятор, который может ускорить некоторые программы Python. В Windows используйте PCbuild/build.bat --experimental-jit чтобы включить JIT или --experimental-jit-interpreter чтобы включить интерпретатор уровня 2. Требования к сборке и дополнительная вспомогательная информация содержатся в
Tools/jit/README.md.

--enable-experimental-jit опция принимает эти (необязательные) значения, по умолчанию yes если --enable-experimental-jit присутствует без необязательного значения.

• no: отключить весь конвейер уровня 2 и JIT.

• yes: Включить JIT. Чтобы отключить JIT во время выполнения, передайте переменную среды PYTHON_JIT=0.

• yes-off: Создайте JIT, но отключите его по умолчанию. Чтобы включить JIT во время выполнения, передайте переменную среды PYTHON_JIT=1.

• interpreter: включить интерпретатор уровня 2, но отключить JIT. Интерпретатор можно отключить, запустив PYTHON_JIT=0.

Внутренняя архитектура примерно следующая:

• Начнем со специализированных Байт-код уровня 1. Видеть Что нового в 3.11 для подробностей.

• Когда байт-код уровня 1 становится достаточно горячим, он преобразуется в новое чисто внутреннее промежуточное представление (IR), называемое Уровень 2 ИРи иногда его называют микрооперациями («uops»).

• IR уровня 2 использует ту же виртуальную машину на основе стека, что и уровень 1, но формат инструкций лучше подходит для перевода в машинный код.

• У нас есть несколько проходов оптимизации для IR уровня 2, которые применяются перед интерпретацией или переводом в машинный код.

• Существует интерпретатор уровня 2, но он в основном предназначен для отладки ранних этапов конвейера оптимизации. Интерпретатор уровня 2 можно включить, настроив Python с помощью --enable-experimental-jit=interpreter.

• Когда JIT включен, оптимизированный IR уровня 2 преобразуется в машинный код, который затем выполняется.

• В процессе трансляции машинного кода используется метод, называемый
  копирование и исправление. У него нет зависимостей во время выполнения, но есть новая зависимость от LLVM во время сборки.

(JIT Брандта Бухера, вдохновленный статьей Хаорана Сюя и Фредрика Кьолстада. IR уровня 2 Марка Шеннона и Гвидо ван Россума. Оптимизатор уровня 2 Кена Джина.)

Определена семантика мутаций для locals()

Исторически сложилось так, что ожидаемый результат изменения возвращаемого значения
locals() определение было оставлено на усмотрение отдельных реализаций Python. Начиная с Python 3.13, ПЭП 667 стандартизирует историческое поведение CPython для большинства областей выполнения кода, но меняет оптимизированные прицелы

(функции, генераторы, сопрограммы, выражения и генераторные выражения) для явного возврата независимых снимков назначенных в данный момент локальных переменных, включая локально ссылающиеся нелокальные переменные, зафиксированные в замыканиях.

Это изменение семантики locals() в оптимизированных областях также влияет на поведение по умолчанию функций выполнения кода, которые неявно нацелены на locals() если явное пространство имен не указано (например, exec() и eval()). В предыдущих версиях можно было получить доступ к изменениям, вызвав
locals() после вызова функции выполнения кода зависело от реализации. В частности, в CPython такой код обычно работает должным образом, но иногда может давать сбой в оптимизированных областях, основанных на другом коде (включая отладчики и инструменты отслеживания выполнения кода), что может привести к сбросу общего моментального снимка в этой области. Теперь код всегда будет работать с независимым снимком локальных переменных в оптимизированных областях, и, следовательно, изменения никогда не будут видны при последующих вызовах locals(). Чтобы получить доступ к изменениям, внесенным в этих случаях, теперь нужно передать явную ссылку на пространство имен соответствующей функции. В качестве альтернативы может иметь смысл обновить затронутый код, чтобы использовать API выполнения кода более высокого уровня, который возвращает результирующее пространство имен выполнения кода (например, runpy.run_path() при выполнении файлов Python с диска).

Чтобы отладчики и подобные инструменты могли надежно обновлять локальные переменные в областях, затронутых этим изменением, FrameType.f_locals теперь возвращает прокси со сквозной записью для локальных и локально ссылающихся нелокальных переменных кадра в этих областях вместо возврата непоследовательно обновляемого общего dict экземпляр с неопределенной семантикой времени выполнения.

Видеть ПЭП 667 для получения более подробной информации, включая связанные изменения и устаревания C API. Примечания по переносу также приведены ниже для затронутых
API-интерфейсы Python и API C.

(PEP и реализация предоставлены Марком Шенноном и Тянь Гао в
gh-74929. Обновления документации предоставлены Гвидо ван Россумом и Алиссой Коглан.)

Поддержка мобильных платформ

ПЭП 730: iOS теперь ПКП 11 поддерживаемая платформа с
arm64-apple-ios и arm64-apple-ios-simulator нацелены на уровень 3 (устройства iPhone и iPad, выпущенные после 2013 года, и симулятор Xcode iOS, работающий на кремниевом оборудовании Apple, соответственно).
x86_64-apple-ios-simulator
(симулятор Xcode iOS, работающий на более старых версиях x86_64 аппаратное обеспечение) не является платформой с поддержкой уровня 3, но будет обеспечена максимальная поддержка. (Написание PEP и реализация предоставлены Расселом Кейт-Маги в
gh-114099.)

ПЭП 738: Android теперь ПКП 11 поддерживаемая платформа с
aarch64-linux-android и x86_64-linux-android цели на уровне 3. 32-битные цели arm-linux-androideabi и i686-linux-android
не являются платформами с поддержкой уровня 3, но будут обеспечены максимальной поддержкой. (PEP написан и реализован Малкольмом Смитом в
gh-116622.)