PEP
| Полное название | Python Enhancement Proposal |
|---|---|
| Появились | 2000 |
| Описание процесса | PEP 1 |
| Кто принимает решения | руководящий совет Python (PEP 13) |
| Типы | Standards Track, Informational, Process |
| Обсуждение | discuss.python.org |
| Каталог | peps.python.org |
PEP (англ. Python Enhancement Proposal — «предложение по улучшению Python») — проектный документ, в котором описывается новая возможность языка Python, изменение процесса разработки или информация для сообщества. PEP содержит техническую спецификацию и обоснование, фиксирует ход обсуждения и итоговое решение. Через PEP прошли почти все крупные изменения Python за последние двадцать с лишним лет — от стиля кода до аннотаций типов и отказа от GIL.
История
Процесс появился в 2000 году, когда разработка Python перешла от небольшой группы к широкому сообществу. Его описывает PEP 1 «Назначение и правила PEP», за образец были взяты документы RFC, по которым принимаются стандарты интернета.[1] Номер 0 зарезервирован за индексом всех PEP.[2]
До 2018 года окончательное решение принимал Гвидо ван Россум. После острого спора вокруг оператора присваивания в выражениях := (PEP 572)[5] он отказался от этой роли, и сообщество выбрало новую модель управления: решения принимает выборный руководящий совет (Steering Council) из пяти человек, переизбираемый после каждого выпуска (PEP 13, PEP 8016).[3][4]
Типы PEP
| Тип | Назначение | Примеры |
|---|---|---|
| Standards Track | новая возможность языка или стандартной библиотеки | PEP 484 (аннотации типов), PEP 634 (сопоставление с образцом) |
| Informational | рекомендации и сведения без обязательных изменений | PEP 20 («Дзен Python»), PEP 257 (строки документации) |
| Process | изменение процессов вокруг Python | PEP 602 (ежегодный цикл выпусков), PEP 13, PEP 8 (формально отнесён к процессным) |
Жизненный цикл
- Идея обсуждается на форуме discuss.python.org, чтобы понять, нужна ли она и не предлагалась ли раньше.
- Автор пишет черновик по шаблону PEP 1 и находит спонсора среди core-разработчиков.
- Редакторы присваивают номер, PEP получает статус Draft.
- Идёт публичное обсуждение, текст дорабатывается.
- Руководящий совет или назначенный им PEP-делегат принимает решение.
Основные статусы:[1]
- Draft — черновик в обсуждении;
- Accepted — принят, реализация ещё не завершена;
- Provisional — принят условно, API может измениться;
- Final — принят и реализован;
- Rejected, Withdrawn, Deferred — отклонён, отозван автором, отложен;
- Superseded — заменён более новым PEP;
- Active — информационный или процессный документ, который действует постоянно.
Отклонённые PEP не удаляются: они остаются в каталоге как запись о том, почему идея не была принята, и экономят время тем, кто захочет предложить её снова.
Структура документа
Каждый PEP начинается с заголовка с метаданными:
PEP: 8
Title: Style Guide for Python Code
Author: Guido van Rossum, Barry Warsaw, Alyssa Coghlan
Status: Active
Type: Process
Created: 05-Jul-2001
Далее следуют обязательные разделы: аннотация, мотивация, обоснование, спецификация, обратная совместимость, вопросы безопасности, «как этому учить», эталонная реализация, отвергнутые идеи и открытые вопросы.
Известные PEP
| Номер | Тема |
|---|---|
| 8 | стиль кода, см. PEP 8 |
| 20 | «Дзен Python» (import this) |
| 257 | соглашения о строках документации |
| 405 | виртуальные окружения, см. Виртуальные окружения (venv) |
| 484 | аннотации типов, см. Типизация в Python (type hints, PEP 484) |
| 492 | async/await, см. asyncio |
| 572 | оператор := |
| 621 | метаданные проекта в pyproject.toml |
| 703 | отключаемый GIL, см. GIL и free-threading (PEP 703) |
Аналоги в других проектах
Схема «предложение — обсуждение — решение» распространилась далеко за пределы Python: в Rust действуют RFC, в Java — JEP, в Kubernetes — KEP, в JavaScript — предложения комитета TC39 со стадиями от 0 до 4. Общая идея — зафиксировать не только решение, но и его мотивы, чтобы через годы было понятно, почему язык устроен именно так.