Как дела, Питон? GIL удален, новый компилятор, optparse устарел…

• Python без GIL, навсегда

• LPython: новый компилятор Python

• Pydantic 2 становится пригодным для использования

• PEP 387 определяет «Soft Deprecation», getopt и optparse soft устарели.

• Выпущен Cython 3.0 с улучшенной поддержкой чистого Python

• PEP 722 — Спецификация зависимостей для однофайловых скриптов

• Поддержка Python VSCode становится быстрее

• Краска в терминале

Мы видели в прошлом месяце гглобальная блокировка интерпретатора вновь оказалась в центре внимания. В этом месяце дело дошло до того, что даже Meta, материнская компания Facebook, вклинился:

Если PEP 703 будет принят, Meta может взять на себя поддержку в виде трех [engineer years on landing] Ногил CPython

Приятно видеть, что Python получает все больше и больше вклада от крупных компаний, которые использовали его для своего успеха. Это огромный контраст по сравнению с десятилетием 2010 г..

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

Это означает, что в ближайшие годы Python удалит свой GIL.

Вот план:

• В краткосрочной перспективе неподдерживаемая экспериментальная версия Python без GIL публикуется параллельно с обычной. Цель 3,13/3,14.

• В среднесрочной перспективе версия без GIL помечена как официально поддерживаемая, но по-прежнему является просто альтернативой Python с GIL. Целевая дата объявляется, чтобы сделать ее по умолчанию один раз. Это произойдет только после того, как сообщество проявит достаточную поддержку, и на это уйдет несколько лет.

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

Обратите внимание, что если программа импортирует одно единственное расширение C, использующее GIL, в сборке без GIL, она предназначена для автоматического переключения обратно на GIL. Так что это не ситуация 2 => 3, когда несовместимый код ломается.

Основная причина двух разных сборок — управлять неизвестными неизвестными. Действительно, никто не ожидает, что отсутствие GIL что-то сломает, но с таким большим проектом никогда нельзя быть уверенным. Совместимость с ABI сложна, и новые расширения должны быть явно скомпилированы для нее, чтобы она работала, поэтому сообщество должно принять ее.

Кроме того, расширения, не совместимые с GIL, будут работать на старом интерпретаторе, поэтому вы не попадете в ситуацию, когда код Python 3 не работает на Python 2.

На самом деле, сам код Python не должен быть затронут и будет без проблем работать как на одном, так и на другом, хотя и с потоками, ограниченными одним ядром с GIL.

Это новость, которой я не ожидал. В “Что делать с CPython, Pypy, MicroPython, Jython…?” мы говорили о компиляторах Python, и мне показалось, что я неплохо потрудился, перечислив все, что имело значение. Что ж, команда разработчиков LPython решил взять этот список и .append() в теме.

LPython — это новый компилятор BSD 3, который берет код Python и транслирует его для использования в LLVM, C, C++ или WASM. Он не предназначен для компиляции всей программы, хотя и может, а скорее, как numba и cython, для того, чтобы позволить вам ускорить числовое узкое место. Контрольные показатели очень перспективны, а возможность переключения между опережением времени и точно в срок очень удобна, хотя вам все равно понадобится вся цепочка компиляции установлена ​​на машине. LPython любит необработанный код Python, поэтому, если вы вызываете функцию Python внутри своего фрагмента, вы должны явно пометить ее как таковую с помощью декоратора. Так что большинство, скорее всего, будут использовать его для очень специфических фрагментов.

Некоторое время я продвигал версию 2 Pydantic, потому что я и многие люди часто использую ее для проверки данных/определения схемы, а новая версия намного быстрее.

Да, он вышел стабильным в прошлом месяце, но если вы читаете “Облегчение проблем с упаковкой Python«Вы знаете, я не призываю людей использовать последнюю версию чего-либо, кроме как для тестирования или развлечения.

Действительно, даже стабильная основная версия по-прежнему нуждается в доработке и по-прежнему мало поддерживается сообществом.

Но сейчас произошли две вещи:

Теперь я попробую его в одном личном проекте, и, если он сработает, перенесу его в профессиональные проекты через несколько месяцев.

Если вы еще не читали блог Виктора Стиннера, я призываю вас это сделать. Это техническое и сырое, без BS, и дает вам хорошее представление о том, что происходит в жизни вклада основного разработчика. Последняя статья упоминает кое-что, что я пропустил в прошлом месяце: мягкое устаревание было добавлено к PEP 387 — Политика обратной совместимости.

Этот документ, созданный в 2009 году, описывает, как проекты Python справляются с устареванием, и теперь он будет содержать следующее:

Мягкое устаревание можно использовать при использовании API, который больше не следует использовать для написания нового кода, но безопасно продолжать использовать его в существующем коде. API остается задокументированным и протестированным, но не будет развиваться дальше (без усовершенствований). Основное различие между «мягким» и (обычным) «жестким» прекращением поддержки заключается в том, что мягкое прекращение поддержки не подразумевает запланированного удаления устаревшего API.

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

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

Первый, разбор аргументов является более современным решением stdlib, и у нас есть хорошая статья о нем.

Во-вторых, сторонние проекты, такие как типы и нажмите существовать.

Китонсамый известный компилятор Python, выпущена версия 3. В то время как релиз поставляется со всеми видами улучшений, одно особенно выделяется. У Cython всегда были ограничения: он использовал надмножество Python для выражения некоторых своих возможностей.

Это больше не так, как отмечается в выпуске: «теперь должна быть возможность выразить весь код Cython и использовать все функции в обычном синтаксисе Python».

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

Хотя тема отказа от GIL, безусловно, все еще жива и здравствует, предложение ПКП 722 Действительно подогрел ситуацию.

Идея состоит в том, чтобы формализовать синтаксис комментариев, аналогичный Groovy’s, позволит выразить зависимость одного скрипта. Взяв пример из самого PEP:

# In order to run, this script needs the following 3rd party libraries
#
# Requirements:
#    requests
#    rich

import requests
from rich.pretty import pprint

resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()
pprint([(k, v["title"]) for k, v in data.items()][:10])

Важные строки:

# Requirements:
#    requests
#    rich

Которые теперь будут официально формализованы для парсинга сторонними инструментами. Концепция не нова, и такие инструменты, как пип-ран уже поддерживают запуск скрипта, для которого у вас есть описанные deps с такими комментариями:

$ pip uninstall rich requests
WARNING: Skipping rich as it is not installed.
WARNING: Skipping requests as it is not installed.
$ pip-run dah_script.py
[
│   ('1', 'PEP Purpose and Guidelines'),
│   ('2', 'Procedure for Adding New Modules'),
│   ('3', 'Guidelines for Handling Bug Reports'),
│   ('4', 'Deprecation of Standard Modules'),
│   ('5', 'Guidelines for Language Evolution'),
│   ('6', 'Bug Fix Releases'),
│   ('7', 'Style Guide for C Code'),
│   ('8', 'Style Guide for Python Code'),
│   ('9', 'Sample Plaintext PEP Template'),
│   ('10', 'Voting Guidelines')
]

Пакеты устанавливаются во временном виртуальная среда и удален после запуска, как npx используется для мира JS.

PEP не подразумевает, что Python или pip собираются интегрировать такую ​​функцию, пока речь идет только о формализации синтаксиса. Но у меня есть большие надежды на это, так как у меня есть несколько одиноких скриптов Python, которые действительно выиграют от этого, особенно если вы сможете сохранить env в будущем. Такое предложение может показать спрос на него, а годы спустя привести к принятию пункта. Например: npx повлиял на добавление npm create, который позволяет получить шаблон проекта из определенных пакетов. Действительно, это был самый распространенный вариант использования npx.

Если вы используете VSCode, вы могли заметить, что использование большого количества линтеров замедляет работу IDE. Mypy особенно виноват, поскольку mypy команда запускается медленно, а режим демона не используется VSCode.

Для его новый выпуск, теперь доступно новое официальное расширение mypy, которое использует демон dmypy. Ускорение такое, что теперь редактор может предлагать проверку всей кодовой базы, а не только текущего файла.

Кроме того, pylance, официальное расширение Microsoft для поддержки Python, теперь будет сохранять всю работу по индексированию, которую он выполняет для сторонних библиотек. Это упростит запуск, а для больших проектов ускорит работу, поскольку индексирование может занять некоторое время на медленных машинах.

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

Это просто круто:

Это версия краски который запускается в терминале благодаря Python lib текстовый

Это не изменит вашу жизнь или что-то в этом роде, но ВАУ.

Я установил его, и он чертовски реактивен. Он даже обрабатывает Ctrl-Z и имеет селектор файлов, когда вы пытаетесь сохранить свою работу.