基本情報

Index of Python Enhancement Proposals (PEPs)

イントロ

このPEPには、すべてのPython Enhancement Proposals（PEP）のインデックスが含まれています。PEP番号はPEPエディターによって割り当てられ、一度割り当てられると変更されることはありません。PEPテキストのバージョン管理履歴は、それらの沿革を表します。

トピック

専門分野のPEPはトピック別にインデックス化されます。

• ガバナンスPEP
• パッケージングPEP
• リリースPEP
• 型付けPEP

カテゴリごとの索引

ここから下の表は、PEPの表を出来るだけ模して作成しています。それぞれに一行増やしてタイトルの日本語訳だけ行いました。記事を書くたびに日本語のところにリンクを貼っていくことを目標にします。なお、PEPのドキュメント番号にあるリンクは公式ページに飛ぶようにしました。

Meta-PEPs (PEPs about PEPs or Processes)

メタPEP(PEPやプロセスについてのPEP)

Other Informational PEPs

その他の情報PEP

Provisional PEPs (provisionally accepted; interface may still change)

暫定的なPEP（仮容認：インターフェースは変更される可能性あり）

Accepted PEPs (accepted; may not be implemented yet)

容認済のPEP（容認済：未実装の可能性あり）

Open PEPs (under consideration)

公開PEP（検討中）

Finished PEPs (done, with a stable interface)

完了したPEP（完了、安定したインターフェース）

Historical Meta-PEPs and Informational PEPs

メタPEPと情報PEPの沿革

Deferred PEPs (postponed pending further research or updates)

繰延になったPEP（今後の調査または更新が保留になっている）

Abandoned, Withdrawn, and Rejected PEPs

放棄、撤退または拒否されたPEP

[speech_bubble type=”ln” subtype=”L1″ icon=”writer.png” name=”管理人”]このセクションのPEPについてはいったん翻訳は飛ばします。取り下げられたものや拒否されたものなので…他ができたらやるかも[/speech_bubble]

Numerical Index

上記カテゴリ別PEPの表をPEPインデックス順に並べ替えただけのものなのでここでは割愛します。

Reserved PEP Numbers

予約済PEP番号

PEP Types Key

PEPのタイプキー

I – Informational PEP（情報PEP）

P – Process PEP（プロセスPEP）

S – Standards Track PEP（標準化過程PEP）

PEP Status Key

PEPのステータスキー

A – Accepted (Standards Track only) （承認済みの提案）

or Active proposal（または、アクティブな提案）

D – Deferred proposal（繰延の提案）

F – Final proposal（最終案）

P – Provisional proposal（仮提案）

R – Rejected proposal（否決案）

S – Superseded proposal（優先度の高い提案）

W – Withdrawn proposal（取り下げられた提案）

Authors/Owners

著者/オーナー（以下は、人の名前であるため訳さずそのまま転記します。）

References

リファレンス

この記事では、PEPの和訳を行い概要やその重要性、そしてPEPの詳細な構造や内容について理解していきます。本記事を通じて、PEPの理解を深め、Pythonの発展に貢献する一助となれば幸いです。

基本情報

Voting Guidelines

アブストラクト

このPEPは、python-devの投票ガイドラインについて概説しています。これらのガイドラインは、特定の提案やアイデア、または機能に関するフィードバックを提供し、あるいは「風向き」を把握するためのものです。これらは拘束力を持ちません。

背景

Pythonコミュニティで新しいアイデア、機能、パッチなどが提案されるとき、おそらくpython-devのメーリングリストで（おそらくpython-dev¹で）行われますが、場合によってはコミュニティ全体の一般的な意見を把握することが有益です。時には、人々は単に自分の意見を登録したいだけです。時にはBDFLがストローポールを取りたい場合もあります。どのような理由があっても、これらのガイドラインは開発者に共通の言語を提供するために採用されています。

意見は（時には）役立つかもしれませんが、それらは決して拘束力を持ちません。理由付きの意見は、裸のスコアよりも常に高く評価されます（特に -1 の投票の場合は特にそうです）。

投票のスコア

スコアリングガイドラインは、Apacheの投票手順²から緩く派生していますが、もちろん我々自身の考えも反映されています。4つの可能な投票スコアがあります。

時々、+2、+1000、または-1000のような投票スコアでの熱狂的なエネルギーの波が見られるかもしれません。これらは、上記のスコアを大幅に超える価値はあまりありませんが、そんなにギークなことに興奮する人々を見るのはいいことです。

リファレンス

1. Python Developer’s Guide, (http://www.python.org/dev/) ↩︎
2. Apache Project Guidelines and Voting Rules (http://httpd.apache.org/dev/guidelines.html) ↩︎

この記事では、PEPの和訳を行い概要やその重要性、そしてPEPの詳細な構造や内容について理解していきます。本記事を通じて、PEPの理解を深め、Pythonの発展に貢献する一助となれば幸いです。

基本情報

PEP Purpose and Guidelines

PEPとは何か？

PEPとは、Python Enhancement Proposal（Python拡張提案）の略称です。PEPは、Pythonコミュニティに情報を提供したり、Pythonやそのプロセスや環境に新機能を記述したりするための設計文書です。PEPは、その機能の簡潔な技術仕様とその機能の理由を提供する必要があります。

PEPは、主要な新機能の提案、問題に対するコミュニティの意見を収集するための手段、およびPythonに関する設計決定を文書化するための主要なメカニズムとして意図されています。PEPの作者は、コミュニティ内での合意形成を推進し、異なる意見を文書化する責任があります。

PEPは、バージョン管理されたリポジトリ内のテキストファイルとして維持されているため、その改訂履歴はその機能提案の歴史記録です。この歴史記録は、古いリビジョンを取得するための通常のgitコマンドによって利用可能であり、GitHubで閲覧することもできます。

PEPの読者

PEPの主な対象読者は、CPythonリファレンスインタープリタのコア開発者と、その選出されたSteering Council、およびPython言語仕様の他の実装の開発者です。

PEPの種類

PEPには三つの種類があります。

Standards Track（標準化過程）

Pythonの新機能や実装について記述します。また、将来のバージョンで標準ライブラリのサポートが追加される前に、現在のPythonバージョンの標準ライブラリの外部でサポートされる互換性のある標準を記述することもあります。

Informational（情報）

Pythonの設計上の問題を説明したり、Pythonコミュニティに一般的なガイドラインや情報を提供したりします。情報提供PEPは、Pythonコミュニティの合意や推奨事項を必ずしも表すものではなく、ユーザーや実装者が情報提供PEPを無視したり、そのアドバイスに従ったりすることができます。

Process（プロセス）

Pythonのプロセスに関する手順や変更を記述します。プロセスPEPは標準トラックPEPと同様ですが、Python言語自体以外の領域に適用されます。プロセスPEPは実装を提案する場合がありますが、Pythonのコードベースには適用されません。通常、コミュニティの合意が必要であり、情報提供PEPとは異なり、推奨事項以上のものであり、ユーザーが無視することが一般的ではありません。PEP 0はプロセスPEPのリストです。

PEPのワークフロー

PythonのSteering Council

このPEPには、”Steering Council”または”Council”という言及がいくつかあります。これは、PEP 13で説明されている選挙されたSteering Councilの現在のメンバーを指します。彼らはPEPが受け入れられるか拒否されるかの最終的な権限を持つ役割を果たしています。

Pythonのコア開発者

このPEPには、”core developers”という言及がいくつかあります。これは、PEP13で説明されている現在のアクティブなPythonコアチームのメンバーを指します。

PythonのBDFL

このPEPの以前のバージョンでは、PEPの決定者に対して「BDFL-Delegate」というタイトルが使用されていました。これは、すべての設計権限がPythonプログラミング言語の元の作成者であるGuido van Rossumから派生していたPythonの以前のガバナンスモデルへの歴史的な言及でした。これに対し、Steering Councilの設計権限は、現在アクティブなコア開発者による選挙によって派生しています。今では、BDFL-Delegateの代わりにPEP-Delegateが使用されています。

PEPエディター

PEPエディターは、PEPワークフローの管理および編集に責任がある個人です（たとえば、PEP番号の割り当てやそのステータスの変更）。詳細については、「PEP Editor Responsibilities & Workflow」を参照してください。

PEPエディターは、現在のエディターの招待によって任命され、GitHubで@python/pep-editorsをメンションすることで連絡を取ることができます。すべてのPEPワークフローは、GitHubのPEPリポジトリの問題とプルリクエストを介して実行できます。

Pythonのアイデアから始める

PEPプロセスは、Pythonに対する新しいアイデアから始まります。1つのPEPには1つの主要提案や新しいアイデアを含めることが強く推奨されており、PEPがより焦点を絞れば絞るほど、成功する可能性が高くなります。ほとんどの機能強化やバグ修正はPEPを必要とせず、直接Pythonの問題トラッカーに提出することができます。PEP編集者は、PEP提案があまりにも焦点が外れたり広範すぎるように見える場合にはPEP提案を拒否する権利を留保しています。疑わしい場合は、PEPをいくつかのよく焦点を絞ったものに分割してください。

各PEPにはチャンピオンが必要です。チャンピオンは、以下に説明するスタイルと形式を使ってPEPを書き、適切なフォーラムで議論を主導し、アイデアについてのコミュニティの合意を築こうとします。PEPチャンピオン（別名：著者）は、まずアイデアがPEP対応可能かどうかを調査することが重要です。これについては、Python DiscourseのIdeasカテゴリに投稿するのが通常最善の方法ですが、より専門的な場合は、Python DiscourseのTypingカテゴリ（静的型付けのアイデア）やPackagingカテゴリ（パッケージングのアイデア）など、適切な場所も考えられます。

PEPを書く前にアイデアを公に検討することは、潜在的な著者の時間を節約することを目的としています。Pythonの変更のために提案された多くのアイデアは、さまざまな理由で拒否されてきました。アイデアがオリジナルかどうか、まずPythonコミュニティに尋ねることは、以前の議論に基づいて保証された拒否のために時間を費やすことを防ぐのに役立ちます（インターネットで検索するだけでは常にうまくいかない）。また、アイデアが著者だけでなく、コミュニティ全体に適用可能であることを確認することも重要です。アイデアが著者にとって良さそうであっても、Pythonが使用されている多くの領域でほとんどの人にとって機能するとは限りません。

チャンピオンがPythonコミュニティにアイデアが受け入れられる可能性があるかどうか尋ねた後、ドラフトPEPを上記で述べた適切な場所に提示する必要があります。これにより、著者はドラフトPEPを細部まで詳細にし、適切にフォーマットされ、高品質にし、提案に関する初期の懸念を解決する機会が得られます。

PEPの提出

上記の初期議論に続いて、PEPの共著者のうち1人以上がコア開発者であるかどうかに応じて、ワークフローが異なります。PEPの共著者のうち1人以上がコア開発者である場合、彼らは以下で概説するプロセスに従う責任があります。そうでない場合（つまり、共著者の誰もがコア開発者でない場合）、PEPの著者はPEPのスポンサーを見つける必要があります。

理想的には、コア開発者のスポンサーが特定されますが、Steering Councilの承認を得て非コアスポンサーも選択できます。GitHubの「PEP editors」チームのメンバーやTyping Council（PEP 729）のメンバーは、スポンサーとして事前承認されています。スポンサーの役割は、PEPの著者がPEPプロセスのロジスティクスを支援するために指導を提供することです（ある種のメンターのように行動します）。スポンサーであることは、その人が後で共著者やPEP-Delegateになることを妨げません（ただし、両方ではありません）。PEPのスポンサーは、ヘッダーの「Sponsor:」フィールドに記録されます。

スポンサーまたはPEPの共著者であるコア開発者がPEPを提出する準備が整ったと判断した場合、提案はGitHubのプルリクエストを介してドラフトPEPとして提出する必要があります。ドラフトは以下で説明するPEPスタイルで書かれている必要があります。そうでない場合は、編集者がすぐにレビューを行います（ただし、編集者が細かいエラーを修正する場合があります）。

標準のPEPワークフローは次のとおりです。

• あなた、PEPの著者は、PEPリポジトリをフォークし、新しいPEPを含む pep-NNNN.rst という名前のファイルを作成します。NNNNは、公開されたまたはPR中のPEPに使用されていない次の利用可能なPEP番号である必要があります。
• 「PEP：」ヘッダーフィールドに、ファイル名に一致するPEP番号をドラフトPEP番号として入力します。
• 「Type：」ヘッダーフィールドに、適切な場合は「Standards Track」、「Informational」、または「Process」を入力し、「Status：」フィールドに「Draft」を入力します。詳細については、PEPヘッダー前文を参照してください。
• 新しいファイルのco-author(s) または sponsorsに書き込みアクセス権がある場合は、.github/CODEOWNERS を更新してください。これにより、将来のファイルの変更のプルリクエストがそれらに割り当てられるようになります。
• これをGitHubのフォークにプッシュし、プルリクエストを送信します。
• PEP編集者は、プルリクエストを構造、フォーマット、その他のエラーに対してレビューします。reST形式のPEPの場合、PEP 12がテンプレートとして提供されています。これは、PEPで使用されるreSTマークアップについて完全な導入を提供します。承認基準は次のとおりです。
  • サウンドかつ完全であること。アイデアは技術的に意味をなさなければなりません。編集者はそれが受け入れられそうかどうかを考慮しません。
  • タイトルが内容を正確に説明していること。
  • PEPの言語（スペル、文法、文章構造など）とコードスタイル（例はPEP 7およびPEP 8と一致する必要があります）が正確であること。PEPテキストは、プルリクエストが送信されるときに正しいreStructuredText形式で自動的にチェックされます。無効なreSTマークアップを持つPEPは承認されません。

編集者は、この初期レビューに関して一般的に寛大であり、問題はレビュープロセスによって修正されることを期待しています。注意：PEPの承認は、恥ずかしい間違いがないことを保証するものではありません！正確さは著者とレビュアーの責任です。

PEPが承認に値しない場合、編集者は具体的な指示と共に著者に返送します。

• 承認されると、PEPに番号が割り当てられます。

レビュープロセスが完了し、PEP編集者が承認すると（これはあなたのPEPを受け入れることとは異なります！）、彼らはあなたのプルリクエストをメインにスクラッシュコミットします。

PEP編集者はPEPの公開を不当に拒否しません。PEPのステータスを拒否する理由には、取り組みの重複、技術的に非合理、適切な動機付けの不足、後方互換性の欠如、Pythonの哲学に沿っていないなどがあります。承認フェーズではSteering Councilに相談することができ、ドラフトのPEP-abilityの最終的な判断者です。

PEPリポジトリに書き込みアクセス権がある開発者は、新しいPEPを作成してコミットすることで直接PEP番号を取得できます。これを行う場合、開発者は通常PEP編集者が担当するタスクを処理する必要があります（PEP Editor Responsibilities & Workflowを参照）。これには、初期バージョンが提出用PEPとしての期待される基準を満たしていることを確認することが含まれます。代わりに、開発者であっても、通常はプルリクエストを介してPEPを提出する必要があります。これを行う場合は、一般にプロセスを自分で処理することが期待されます。PEP編集者からの支援が必要な場合は、GitHubで @python/pep-editors をメンションしてください。

更新が必要な場合、PEPの著者は（または共同開発者が）PEPリポジトリに書き込みアクセス権がある場合は新しいバージョンをチェックインできます。PEP番号が早期に割り当てられると、複数のドラフトPEPが同時に検討されている場合に便利です。

Standards Track PEPは、設計文書と参照実装の2つの部分で構成されています。原則として、少なくともプロトタイプ実装がPEPと共同開発されることが推奨されます。原理的に良さそうなアイデアでも、実装のテストに耐えると実際には非実用的である場合があります。

PEPの議論

PEP番号が割り当てられ、ドラフトPEPがPEPリポジトリにコミットされると、PEPの議論と内容のレビューのための中心的な場所を提供するために、PEPのための議論スレッドを作成するべきです。また、PEPは更新され、その議論スレッドへのリンクがDiscussions-Toヘッダーに含まれるように更新されるべきです。

PEPの著者（または適用される場合はスポンサー）は、以下の基準が満たされる限り、議論のための任意の合理的な場所を選択することができます。

• フォーラムがPEPのトピックに適していること。
• スレッドがウェブ上で一般に利用可能であり、すべての関係者が参加できること。
• 議論がPython Community Code of Conductの対象となること。
• PEPのDiscussions-Toヘッダーに、現在の議論スレッドへの直接リンクが提供されていること。 PEPsカテゴリのPython Discourseが、ほとんどの新しいPEPにとっての優れた選択肢ですが、歴史的にはPython-Devメーリングリストが一般的に使用されていました。一部の特殊なトピックには、TypingカテゴリやPython DiscourseのPackagingカテゴリなど、特定の場所があります。PEPの著者が最適な場所を選択できない場合は、PEPスポンサーやPEP編集者が適切なアドバイスを提供できます。

PEPが大幅に書き換えられたり、提案された仕様に大きな実質的な変更がある場合は、通常、選択した場所で新しいスレッドを作成して追加のフィードバックを求める必要があります。このような場合、Discussions-Toリンクを更新し、この新しいスレッドを指す新しいPost-Historyエントリを追加する必要があります。

議論の場所として選択されない場合、PEPsカテゴリに少なくともレンダリングされたPEPへのリンクと、PEPがリポジトリにコミットされたとき、および新しいスレッドがトリガーされるほどの大きな変更が行われたときに、議論スレッドへのリンクが少なくとも含まれる簡単なアナウンスポストを作成する必要があります。

PEP著者は、PEPをレビューする前にコミュニティのフィードバックを収集する責任があります。ただし、長々とした無限の議論を避けるために、早い段階でのプライベートやより狭い範囲のフィードバックを求めたり、PEPの主題に詳しい他のコミュニティメンバーと協力したり、PEPのトピックに適した適切な専門的なディスカッションを選択したりする戦略を考慮する必要があります。PEP著者は、ここで自己裁量を行使する必要があります。

一旦PEPに番号が割り当てられ、PEPリポジトリにコミットされると、根本的な問題は一般的に公式の公開スレッドで議論されるべきです。これにより、誰もがフォローし、貢献することができ、議論が断片化されるのを防ぎ、PEPのレビュープロセスの一部として十分に考慮されるようになります。指定されたスレッドへのコメント、サポート、懸念、その他のフィードバックは、Steering CouncilまたはPEP-DelegateがPEPをレビューする際に考慮される重要な部分です。

PEPのレビューと解決策

著者がPEPを完成させたら、PEP編集者にスタイルと一貫性のレビューを要求することができます。ただし、PEPの内容のレビューと受け入れは最終的にはSteering Councilの責任であり、著者（およびスポンサーがいる場合）がPEPが最終的なレビューと解決の準備が整ったと判断した後、Steering Councilの問題を開くことによって正式に開始されます。

選択された場合にプロセスを迅速化するために（例えば、変更が明らかに有益で受け入れる準備が整っているが、PEPがまだ正式にレビューに提出されていない場合など）、Steering CouncilはPEPレビューを開始することもできます。まず、PEP著者に通知し、彼らが修正を行う機会を与えます。

PEPの承認権限は、Steering Councilにあります。ただし、新しいPEPが提出されると、そのPEPの最終的な決定を下すのに適切な経験を持っていると考えるコアデベロッパーは、Steering Councilに自分がPEP-Delegateとして奉仕する意向を通知することによって、そのPEPのPEP-Delegateとして自己任命することができます。Steering Councilがその提供を承認すると、PEP-DelegateはそのPEPを承認または拒否する権限を持つようになります。Pythonの型システムに関連するPEPの場合、Typing Council（PEP 729）はSteering Councilに推奨を提供します。そのような推奨をリクエストするには、Typing Councilの問題トラッカーで問題を開きます。

用語「PEP-Delegate」は、PEPの指定された意思決定者を表すためにSteering Councilのガバナンスモデルで使用され、PEPのヘッダーの「PEP-Delegate」フィールドに記録されます。用語「BDFL-Delegate」は、PEP-Delegateの非推奨のエイリアスであり、PythonがBDFLによって指導されていた時代の遺産です。 「BDFL-Delegate」への過去の参照は、「PEP-Delegate」と同等であるとみなされるべきです。

PEP-Delegateとして自己指名する個人は、関連する著者と（存在する場合）PEPのスポンサーに通知し、Steering Councilにリクエストを提出する必要があります（新しい問題を介して行うことができます）。この責任を負う者は、いつでもSteering Councilから追加のガイダンスを求めることができ、他のコアデベロッパーの助言と視点を考慮することも期待されます。

Steering Councilは通常、自己指名をデフォルトで承認しますが、拒否することもあります。 Steering Councilが自己指名を拒否する可能性のある理由には、潜在的な利害の衝突の認識（例：PEP提出者と同じ組織で働いている場合）、または単に別の潜在的なPEP-Delegateがより適切だと見なす場合などがあります。コアデベロッパー（または他のコミュニティメンバー）が特定のPEP-Delegateの適格性に懸念を抱く場合、Steering Councilに委任の再評価を依頼することができます。

自発的なボランティアが現れない場合、Steering Councilは、該当する専門知識を持つコアデベロッパー（および他のPythonコミュニティメンバー）にアプローチし、そのPEPのPEP-Delegateとして奉仕する意思のある候補者を特定しようとします。適切な候補者が見つからない場合、PEPは利用可能なまで一時停止されます。

以前に指名されたPEP-Delegateは、辞任することも求められる場合があります。この場合、新しいPEP-Delegateは見つからない場合、同様の方法で新しいPEP-Delegateが指名されます（PEPが見つからない場合は、PEPを一時停止する必要があります）。PEP-Delegateが辞任するように要求された場合、これはPEPの以前の受け入れまたは拒否を覆い、PEPをドラフト状態に戻します。

このような常設委任が設けられると、Steering Councilは、その委任が現在存在する理由、その理由がなぜ生じたか、それが必要でなくなる場合の状況を理解できるようにするために、十分な公開記録を維持します。

PEPが受け入れられるためには、一定の最小基準を満たす必要があります。提案された改良の明確で完全な説明でなければなりません。改良は純粋な改善を表していなければなりません。適用可能な場合、提案された実装は堅実であり、インタプリタを不必要に複雑にしないものでなければなりません。最後に、提案された改良は「Pythonic」でなければなりません。ただし、「Pythonic」は不明瞭な用語であり、Steering Councilが受け入れ可能と見なすものと定義することができます。この論理は意図的に循環しています。標準ライブラリモジュールの受け入れ基準については、PEP 2を参照してください。

Steering Councilの承認によって許可されていない場合を除き、PEPの解決の宣言はPython DiscourseのPEPsカテゴリに投稿されます。

PEPが受け入れられると、参照実装が完成する必要があります。参照実装が完了し、メインのソースコードリポジトリに組み込まれると、ステータスが「Final」に変更されます。

言語機能や標準ライブラリAPIの長期安定性を確保する前に追加の設計やインターフェースのフィードバックを集めるために、PEPは「Provisional」としてマークされる場合もあります。これは、「Provisionally Accepted」の略であり、提案が参照実装に含まれることが受け入れられたが、完全な設計を「Final」と見なす前に追加のユーザーフィードバックが必要であることを示します。通常の受け入れられたPEPとは異なり、一時的に受け入れられたPEPは、関連する変更がPythonリリースに含まれた後でも「Rejected」または「Withdrawn」になる可能性があります。

可能な限り、広範囲のPythonエコシステムでバージョン互換性の課題を引き起こす可能性があるため、「Provisional」ステータスに頼らずに提案の範囲を縮小することが望ましいと考えられています（例：後続のPEPに一部の機能を遅延させることによって）。PEP 411は、「Provisional」ステータスの潜在的な使用事例に関する追加の詳細を提供しています。

PEPはまた、「Deferred」というステータスが割り当てられる場合もあります。PEPの進行状況が全く進まない場合、PEP著者または編集者がこのステータスをPEPに割り当てることができます。一度PEPが延期されると、PEPエディターはそれをドラフト状態に戻すことができます。

PEPはまた、「Rejected」になる可能性があります。最後には良いアイデアではなかったかもしれません。この事実の記録を持つことは依然として重要です。「Withdrawn」ステータスは類似しており、PEPの著者自身がそのPEPが実際には悪いアイデアであることを決定したか、または競合する提案がより良い代替手段であることを受け入れたことを意味します。

PEPが受け入れられた、拒否された、または取り下げられた場合、PEPはそれに応じて更新される必要があります。ステータスフィールドを更新するだけでなく、少なくともResolutionヘッダーを追加し、PEPに対する決定を直接リンクする必要があります。

PEPは、異なるPEPによって取って代わられる場合もあります。これにより、元のPEPが古くなります。これは、情報提供PEPの場合に意図されており、APIのバージョン2がバージョン1を置換することができます。

PEPのステータスの可能なパスは次のとおりです：

PEPプロセスのフローダイアグラム ダイアグラムには表示されていませんが、「受け入れられた」PEPは、受け入れ前に気付かれなかった設計上の根本的な欠陥が実装プロセスで明らかになった場合にのみ、「拒否」または「取り下げ」に移行することができます。これらの遷移は、Provisional PEPの場合にのみ許可されます。これらの遷移は、リリースされた変更が通常の非推奨プロセスを経て（新しいPEPが非推奨化の理由を提供する場合がある）行われるためです。

一部の情報提供PEPおよびプロセスPEPは、決して完了することを意図していない場合、「Active」というステータスを持つ場合もあります。たとえば、PEP 1（このPEP）。

(Note: 「プロビジョニング」の部分は、正式な翻訳がありませんので、そのままの表記となっています。)

PEPのメンテナンス

一般的に、PEPは受け入れられた、Final、拒否された、または取り下げられた状態に達した後、大幅に修正されることはありません。解決が得られると、PEPは生きている仕様ではなく、歴史的な文書と見なされます。形式的な振る舞いの文書化は、コア機能の場合は言語リファレンス、標準ライブラリモジュールの場合はライブラリリファレンス、パッケージングの場合はPyPA仕様など、他の場所で維持する必要があります。

Provisionalまたは（SCの承認付きで）受け入れられた状態での実装経験とユーザーフィードバックに基づく変更がStandardsトラックPEPに行われる場合、それらはPEPに記載されるべきです。これにより、PEPがFinalにマークされた時点で実装を正確に説明することができます。

アクティブ（情報提供およびプロセス）PEPは、開発プラクティスやその他の詳細の変更を反映するために、時間の経過とともに更新される場合があります。これらの場合における具体的なプロセスは、対象のPEPの性質と目的に依存します。

時折、DeferredまたはWithdrawnのPEPが大幅な更新とともに復活することがありますが、新しい提案をする方が良い場合もよくあります。

成功したPEPには何がふくまれている必要があるか

成功したPEPには、以下のパート/セクションが含まれる必要があります。

1. 前置部 – PEPに関するメタデータを含むRFC 2822スタイルのヘッダー。これには、PEP番号、短い説明的なタイトル（最大44文字まで）、各著者の名前、オプションで連絡先情報などが含まれます。
2. 要約 – 扱う技術的問題の短い（約200語）説明。
3. 動機 – Python言語、ライブラリ、またはエコシステムを変更するPEPには動機が重要です。既存の言語仕様が、PEPが解決する問題を解決するのに不十分である理由を明確に説明する必要があります。Pythonエコシステムの重要なプロジェクトからPEPへの文書化されたサポートを収集することが含まれる場合もあります。十分な動機がないPEP提出は拒否される場合があります。
4. 根拠 – 根拠は、特定の設計決定がなされた理由を説明することで仕様を具体化します。考慮された代替設計と関連する作業（たとえば、他の言語での機能サポート方法など）を説明する必要があります。
5. 仕様 – 技術仕様には、新しい言語機能の構文と意味論を記述する必要があります。仕様は、少なくとも現在の主要なPythonプラットフォーム（CPython、Jython、IronPython、PyPy）で競合し、相互運用可能な実装を可能にするほど詳細である必要があります。
6. 後方互換性 – 後方互換性のない変更を導入するすべてのPEPには、これらの非互換性とその重大性について説明するセクションが含まれている必要があります。PEP提出時に、これらの非互換性にどのように対処するかを説明する必要があります。十分な後方互換性の議論がないPEP提出は、拒否される場合があります。
7. セキュリティの影響 – PEPに関連するセキュリティ上の懸念がある場合は、それらの懸念を明示的に記述する必要があります。
8. この方法を教える – 新しい機能を追加するか言語の動作を変更するPEPの場合、ユーザーがそのPEPをどのように適用し、コードを移行するかをユーザーに教えるためのセクションを含めると役立ちます。
9. 参照実装 – 参照実装は、どのPEPも「Final」というステータスが付与される前に完成していなければなりませんが、PEPが受け入れられる前に完成していなくても構いません。仕様と根拠について合意に達すると、コードを書く前の方針「大雑把な合意と動作するコード」の原則も依然として有用です。
10. 最終的な実装には、Python言語リファレンスまたは標準ライブラリリファレンスに適したテストコードとドキュメントが含まれている必要があります。
11. 拒否されたアイデア – PEPの議論中には、受け入れられなかったさまざまなアイデアが提案されることがあります。これらの拒否されたアイデアは、なぜそれらが最終的に追求されなかったかの理由とともに記録されるべきです。これにより、PEPの最終バージョンの思考プロセスが記録されるだけでなく、後続の議論で同じ拒否されたアイデアが再び持ち上げられるのを防ぐことができます。
12. このセクションは、特定のアイデアが最終的に追求されなかった理由に特化したRationaleセクションの分割セクションと考えることができます。
13. オープンイシュー – PEPがドラフトの状態にある間、さらなる議論が必要なアイデアが出てくることがあります。これらのアイデアは、完全な解決策がないことを示すために記録されるべきです。これにより、PEPが検討の対象となる準備が整っている必要なすべての問題が完了し、人々が以前の議論を重複するのを減らすことができます。
14. 脚注 – PEPで引用される脚注のコレクション、および非インラインのハイパーリンクターゲットをリストする場所。
15. 著作権/ライセンス – 各新しいPEPは、パブリックドメインおよびCC0-1.0-Universalのデュアルライセンスの下に配置される必要があります。

PEPフォーマットとテンプレート

PEPは、UTF-8でエンコードされたテキストファイルであり、reStructuredText形式を使用しています。reStructuredTextは豊富なマークアップを可能にし、それでも読みやすいテキストを提供しますが、見栄えがよく、機能的なHTMLにも変換されます。PEP 12には手順とPEPテンプレートが含まれています。

PEPテキストファイルは、オンラインでの読みやすさのためにHTMLに自動変換されます（Sphinxベースのビルドシステムを使用）。

PEPのヘッダー前文

各PEPは、RFC2822スタイルのヘッダープリアンブルで始まる必要があります。ヘッダーは以下の順序で表示される必要があります。ヘッダーのうち、「*」でマークされたものはオプションであり、以下で説明します。それ以外のすべてのヘッダーは必須です。

PEP	pep number（PEP番号）
Title	pep title（PEPのタイトル）
Author	list of authors’ real names and optionally, email addrs （著者の本名とメールのリスト）
* BDFL-Delegate	PEP czar’s real name（PEP czarの本名）
* Discussions-To	email address（Eメールアドレス）
Status	Draft（草案）
	Active（アクティブ）
	Accepted（承認）
	Provisional（仮）
	Deferred（延期）
	Rejected （拒否）
	Withdrawn（撤回）
	Final（完了）
	Superseded（置換）
Type	Standards Track（標準化過程）
	Informational（情報）
	Process（プロセス）
* Content-Type	text/x-rst
	text/plain
* Requires	pep numbers（PEP番号）
Created	date created on, in dd-mmm-yyyy format （dd-mmm-yyyy形式の作成日）
* Python-Version	version number（バージョン番号）
Post-History	dates of postings to python-ideas and/or python-dev （python-ideasやpython-devへの投稿日）
* Replaces	pep number（PEP番号）
* Superseded-By	pep number（PEP番号）
* Resolution	url

著者の場所には、PEPのすべての作者/所有者の名前と、オプションで電子メールアドレスのリストが表示されます。形式は次のとおりです。以下がメールアドレスを含む場合

Random J. User <address@dom.ain>

次に、メールアドレスを含まない場合

Random J. User

複数の著者がいる場合は、各著者をRFC 2822の継続行規則に従って別々の行に記述する必要があります。なお、PEP内の個人のメールアドレスは、スパムハーベスターに対する防御として非表示にされます。

Sponsorフィールドは、どの開発者（コア、またはステアリング評議会によって承認された開発者）がPEPをスポンサーしているかを記録します。PEPの著者がコア開発者の場合、スポンサーは必要ありません。したがって、このフィールドは省略してください。

PEP-Delegateフィールドは、ステアリング評議会によって任命された個人がPEPを承認または拒否する最終的な決定を記録するために使用されます。

注：Resolutionヘッダーは、スタンダードトラックPEPにのみ必要です。このヘッダーには、PEPの承認または拒否に関する発表（URL）を含める必要があります。

Discussions-Toヘッダーは、PEPの現在の正規のディスカッションスレッドへのURLを提供します。メーリングリストの場合、これはリストのアーカイブ内のスレッドへの直接リンクである必要があります。単にmailto：やリスト自体へのハイパーリンクではありません。

Typeヘッダーは、PEPのタイプを指定します：スタンダードトラック、情報、またはプロセス。

オプションのTopicヘッダーには、PEPが所属する特定のトピックがリストされます。既存のトピックについては、トピックインデックスを参照してください。

Createdヘッダーには、PEPに番号が割り当てられた日付が記録されます。Post-Historyは、PEPのDiscussions-Toスレッドの日付とそれに対応するURLが記録されます。日付はすべてdd-mmm-yyyy形式で指定する必要があります（例：14-Aug-2001）。

スタンダードトラックPEPには通常、Python-Versionヘッダーが含まれます。これは、機能がリリースされるPythonのバージョンを示します。Python-VersionヘッダーがないスタンダードトラックPEPは、最初は外部ライブラリやツールを介した相互運用性規格をサポートし、その後、標準ライブラリにサポートを追加するための後続のPEPによって補完されることを意味します。情報およびプロセスPEPにはPython-Versionヘッダーは不要です。

PEPには、このPEPが依存しているPEP番号を示すRequiresヘッダーが含まれる場合があります。

PEPには、後続の文書によってPEPが廃止されたことを示すSuperseded-Byヘッダーが含まれる場合があります。値は、現在の文書を置き換えるPEPの番号です。新しいPEPには、現在の文書を廃止したことを示すReplacesヘッダーが含まれている必要があります。

補助ファイル

PEPには、ダイアグラムなどの補助ファイルを含めることができます。そのようなファイルは、pep-XXXX-Y.extという名前でなければなりません。「XXXX」はPEP番号、「Y」はシリアル番号（1から始まる）、そして「ext」は実際のファイル拡張子（例：「png」）に置き換えられます。

また、すべてのサポートファイルをpep-XXXXという名前のサブディレクトリに配置することもできます。「XXXX」はPEP番号です。サブディレクトリを使用する場合、ファイルの名前に制約はありません。

既存のPEPの変更

ドラフトPEPは、提出されるまでの間、著者の裁量によって自由に議論と提案の変更が可能です。実質的な内容の変更は、一般的にはPEPのDiscussions-ToヘッダーにリストされているPEPのディスカッションスレッドで最初に提案されるべきですが、コピーエディットや訂正はGitHubの問題またはGitHubのプルリクエストとして提出できます。PEPリポジトリに書き込みアクセス権を持つPEP著者は、git pushまたはGitHubのPRを使用して自分自身でPEPを更新できます。他のPEPの変更方法については、PEPメンテナンスセクションを参照してください。

詳細については、貢献ガイドを参照してください。疑問がある場合は、まずPEPの著者やPEPエディターに確認してください。

PEPの所有権の譲渡

時々、PEPの所有権を新しいチャンピオンに移管する必要が生じます。一般的に、元の著者を移管されるPEPの共同著者として保持することが望ましいですが、これは元の著者によって決定されます。所有権を移管する良い理由は、元の著者が更新やPEPプロセスのフォローアップに時間や興味を持っていないか、インターネット上から消えてしまった場合です（つまり、連絡が取れないか、メールに反応しない場合）。PEPの方向に同意しないから所有権を移転するのは悪い理由です。PEPプロセスの目標の1つは、PEPを取り巻く合意を築こうとすることですが、それが不可能な場合、著者は常に競合するPEPを提出することができます。

PEPの所有権を引き継ぐことに興味がある場合は、プルリクエストを使用してこれを行うこともできます。PEPリポジトリをフォークし、所有権の変更を行い、プルリクエストを送信してください。プルリクエストのコメントで、元の著者と@python/pep-editorsの両方を言及する必要があります。（元の著者のGitHubのユーザー名がわからない場合は、メールを使用してください。）元の著者が適時に応答しない場合、PEPエディターは一方的な決定を行います（このような決定が元に戻せないわけではありません：）。

PEP編集者の責任とワークフロー

PEPエディターは、GitHub上の@python/pep-editorsグループに追加され、PEPリポジトリをウォッチする必要があります。

なお、PEPリポジトリへの書き込みアクセス権を持つ開発者は、通常PEPエディターが担当するタスクを処理することができます。また、開発者でさえも、GitHubで@python/pep-editorsをメンションしてPEPエディターからの支援を要求することができます。

新しいPEPが入ってくるたびに、エディターは以下の作業を行います：

• PEPがコア開発者によって共著されているか、スポンサーとしてコア開発者が指名されているか、またはステアリング評議会によってこのPEPのために特別に承認されたスポンサーがいることを確認します。
• PEPが準備ができているかどうかを確認します：技術的に妥当で完全である必要があります。アイデアは技術的に意味をなす必要がありますが、受け入れられる可能性が低くても構いません。
• タイトルが内容を正確に説明していることを確認します。
• ファイル名の拡張子が正しいこと（.rstであること）を確認します。
• PEPリポジトリへの書き込みアクセス権を持つすべてのスポンサーや共著者が.github/CODEOWNERSに追加されていることを確認します。
• 言語（つまり、スペル、文法、文章構造など）やコードスタイル（例はPEP 7＆PEP 8に準拠する必要があります）の明らかな欠陥を確認し、修正します。エディターは問題を自分で修正することができますが、それをする必要はありません（reStructuredText構文はリポジトリのCIによってチェックされます）。
• プロジェクトがPEPを支持またはサポートしていると描かれている場合、そのサポートが明確に示されるように、プロジェクトからの直接的な表示が含まれていることを確認します。これは、PEPが実際にはサポートしていないプロジェクトを誤って支持していることを避けるためです。
• PEPが準備ができていない場合、エディターは具体的な指示を添えて、著者に修正するように返します。reSTフォーマットが問題なら、著者にPEP 12をテンプレートとして使用するように指示し、再提出してもらいます。

PEPがリポジトリに準備ができている場合、PEPエディターは次の作業を行います：

• 著者が有効なPEP番号を選択したか、または選択しなかった場合は番号を割り当てます（ほとんどの場合、次の利用可能な番号ですが、場合によっては特別な/ジョークの番号、例えば666または3141です）。
• 100未満の番号はメタPEPです。
• 著者がPEPのタイプ（「スタンダードトラック」、「情報」、または「プロセス」）を正しくラベル付けし、「Draft」としてそのステータスをマークしていることを確認します。
• すべてのCIビルドとリントチェックがエラーなしでパスし、レンダリングされたプレビュー出力に明らかな問題がないことを確認します。
• 新しい（または更新された）PEPをマージします。
• 著者に次の手順（ディスカッションスレッドを開く、PEPを更新するなど）を通知します。

既存のPEPの更新は、GitHubのプルリクエストとして提出する必要があります。

多くのPEPは、Pythonコードベースへの書き込みアクセス権を持つ開発者によって書かれ、メンテナンスされています。PEPエディターはPEPリポジトリを監視し、見逃した構造、文法、スペル、またはマークアップの間違いを修正します。

PEPエディターはPEPに判断を下しません。彼らは通常、管理上および編集上の作業（通常は低いボリュームのタスク）を行います。

Resources:

• Index of Python Enhancement Proposals
• Following Python’s Development
• Python Developer’s Guide