Кратко

  • Процесс PEP в Python разделяет публичное обсуждение, решение Steering Council или утверждённого PEP-Delegate, эталонную реализацию, её включение в главный исходный репозиторий и ограничения стадий релиза.
  • В квитанции от решения до релиза должны отдельно сохраняться PEP, уполномоченный решающий, резолюция, ревизия, ветка, стадия и артефакт; слово Accepted не должно подменять поставку.

У короткого статуса слишком много возможных значений

Фраза «Python принял изменение» может означать появление корректно оформленного PEP, живое публичное обсуждение, решение Council, решение делегата по конкретному PEP, включение кода в CPython или выпуск конечной версии. Эти события часто идут в одной истории, но не являются взаимозаменяемыми доказательствами. Для сопровождающей команды важнее не красота формулировки, а ответ на вопрос: какой именно переход подтверждён?

PEP 1 описывает PEP как документ проектирования. Он собирает крупное предложение, обратную связь, обоснование и несогласие. Автор обязан искать консенсус и фиксировать возражения. Такая работа делает решение проверяемым, но не превращает число участников в полномочие принять решение и не создаёт выпускной пакет.

Полезно различать действия в их собственной последовательности. Редакционная проверка определяет, достаточно ли документ оформлен; она не принимает технический замысел. Обсуждение испытывает замысел; оно не вводит артефакт в эксплуатацию. Резолюция решает судьбу PEP; она не доказывает, что код завершён. Ревизия в репозитории связывает замысел с реализацией; она не равна стабильному релизу. У каждого шага свой предмет и свой след.

Полномочие Delegate ограничено конкретным PEP

Окончательная власть по принятию PEP принадлежит избранному Steering Council. Core developer может предложить себя в качестве PEP-Delegate для определённого предложения. Если Council одобряет это предложение, делегат вправе принять или отклонить именно этот PEP. Вопрос о пригодности делегата также может быть передан Council.

Это не личное правление и не декоративная комиссия. Это ограниченное делегирование: техническое суждение оказывается ближе к предмету, но остаётся видимая цепочка назначения, возражения и последней ответственности. Объём полномочия — названный PEP, а не все решения о языке, все ветки и не будущая дата выпуска.

PEP 13 определяет Council как орган с широкими полномочиями, который должен искать консенсус до формального действия, может делегировать часть полномочий и служит последней апелляционной инстанцией, когда иные способы не сработали. Широта этой роли не позволяет приклеивать её к каждому commit. Имя делегата тоже не является доказательством того, что ветка стабилизирована или что релиз обещан.

Accepted, Final и released — разные узлы доказательств

PEP 1 требует: после принятия PEP эталонная реализация должна быть закончена и включена в главный репозиторий исходного кода, прежде чем статус станет Final. Следовательно, Accepted не подтверждает готовый код. Final соединяет решение по дизайну с завершённой эталонной реализацией; это не просто более сильное слово.

Даже Provisional не является общей гарантией. Временно принятый PEP может быть отклонён или отозван после того, как связанные с ним изменения появились в выпуске Python. Статус не доказывает универсальную совместимость, принятие всеми пользователями или отсутствие будущих исправлений.

Отдельная граница появляется в цикле разработки. Новые возможности движутся в ветке разработки. При первой beta создаётся maintenance branch: текущий цикл стабилизируется, а следующий продолжает движение в main. На стадии release candidate допустимы только проверенные исправления достаточно серьёзных ошибок. При выпуске финальной версии изменять соответствующую ветку может только release manager. Это защита конкретного процесса стабилизации, а не передача решения по PEP менеджеру релиза и не разрешение принятому PEP обойти эти ограничения.

Квитанция, которая связывает, но не смешивает

Для решения следует хранить номер и редакцию PEP, каноническое обсуждение, решающего, делегирование при наличии, ссылку на резолюцию и статус. Следует также прямо назвать то, что решением не установлено: целевая версия, backport, готовность реализации или срок. Для реализации добавляются эталонная ревизия, репозиторий, ветка и открытые тесты либо рецензии. Для релиза — ветка, стадия, идентификатор артефакта, действие release manager и опубликованная версия.

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

Источники

  1. PEP 1 — PEP Purpose and Guidelines
  2. PEP 13 — Python Language Governance
  3. Python Developer’s Guide — Development cycle
  4. Lu Heng, The Multi-Stakeholder Mirage
  5. Lu Heng, Running-Code Primacy