As rookie

ルーキーインフラエンジニアがインフラのこと以外も結構書いてしまうブログ

【PEPを読もう】Purpose and Guidelines【PEP 1】

PEPを読もう

PEPにまとめられている情報により設計や思想を知れます。
Pythonを深く知りたいなら読んだ方が良さそう。ということで読んでいきます。

日本語に翻訳されているPEP一覧 というページを見つけました。
PEPIndex - Python Japanese Environment Wiki - Python Japanese Environment - OSDN

PEP 1

PEP 1 -- PEP Purpose and Guidelines | Python.org

PEP 1 はPEPの目的とガイドラインです。Process PEPです。

PEPのガイドラインである。Pythonに対して提案などを行いたい場合に参照するのが良い。開発ワークフローで対応できる改善提案やパッチは issue tracker にパッチを送ろう。

PEPとは

  • Python Enhancement Proposal の略
  • Pythonコミュニティに情報を提供したり、Pythonまたはそのプロセスや環境の新機能を説明したりする設計ドキュメント
  • Pythonに取り入れられた設計上の決定を文書化するための主要なメカニズムになることを意図している。

PEP Type

  • I
    • Informational PEP
    • Python の設計上の問題を記述したり、Python コミュニティに一般的なガイドラインや情報を提供したりしますが、新しい機能を提案するものではありません。Informational PEPは必ずしもPythonコミュニティのコンセンサスや勧告を表しているわけではないので、ユーザーや実装者はInformational PEPを無視するか、彼らのアドバイスに従うかは自由です。
  • P
    • Process PEP
    • Pythonを取り巻くプロセスを記述したり、プロセスへの変更(またはプロセス内のイベント)を提案したりします。Process PEPは Standards Track PEPのようなものですが、Python言語以外の領域に適用されます。これらは実装を提案することはできますが、Pythonのコードベースに対しては提案しません。例としては、手順、ガイドライン、意思決定プロセスへの変更、Python開発で使用されるツールや環境への変更などがあります。どんなメタPEPもProcess PEPとみなされます。
  • S
    • Standards Track PEP
    • Standards Track PEP は Python の新しい機能や実装を記述します。また、後続のPEPが将来のバージョンで標準ライブラリのサポートを追加する前に、現在のPythonのバージョンで標準ライブラリの外でサポートされる相互運用性の標準を記述することもあります。

ワークフロー

ワークフローはPEPに提案を行いたい場合に参照すると良い。 メモを簡潔にまとめる。

登場人物

  • Pythonの運営評議会
    • PEP13に記載された選出された運営評議会のメンバーに承認・拒否の権限がある。
  • Python コアデベロッパー
    • PEP13で説明されているアクティブなPYthonコアチームメンバー
  • PythonのBDFL（優しい終身の独裁者 - Wikipedia）
    • このPEPの以前のバージョンでは、PEPの意思決定者に「BDFL-Delegate」というタイトルが使用されていた。
    • 現在は PEPの意思決定者が意思決定を行っている。

メモ

  • 1つのPEPには1つの提案だけを含めるようにするのが良い。
  • PEP作成者（提案者）はチャンピオンと呼ばれている
  • PEPとして提案する前に、アイディアを共有するメーリングリストに投稿して意見をもらったほうが良い。
    • "Just because an idea sounds good to the author does not mean it will work for most people in most areas where Python is used."
  • PEPの著者がコア開発者かどうかでフローが変化する。
    • コア開発者でない場合は、スポンサー（メンターのようなもの）が付く
  • GitHubのプルリクエストを介して提案をドラフトのPEPとして提出する。
    • PEPスタイルでプルリクエストを作成する必要がある。
  • Travis CIによってフォーマットチェックされる
  • PEPを拒否する理由には以下のようなものがある。
    • 作業の重複
    • 技術的に不健全
    • 適切な動機づけを提供していない
    • 下位互換性に対処していない
    • Pythonの哲学に沿っていない。
  • PEP承認の最終的な権限は運営評議会（Steering Council）
    • 最終決定を下すのに適切な経験があるコア開発者は代理人として役割を果たすことができる。
  • PEP-Delegatesは評議会から辞任を求められる可能性がある（そういうフローがある。）
  • 最後に、提案された拡張機能は、運営評議会によって受け入れられるために「pythonic」でなければなりません。
    • （ただし、「pythonic」は不正確な用語です。SteeringCouncilに受け入れられるものとして定義される場合があります。このロジックは意図的に循環しています。）
  • PEPのステータスは画像の通り。 f:id:shigeru-mokicks:20210526011514p:plain

その他

  • 成功しやすいPEPの特徴についてまとめられている。
  • 各PEPは、RFC822スタイルのヘッダープリアンブルで始まる必要がある。
  • 変更をどこに送信するかについて疑問がある場合は、最初にPEP作成者またはPEPエディター（あるいはその両方）に確認するのが良い。
  • PEPの所有権を譲渡することができる。
    • GitHub で フォークして所有者を変更してPRを出す
  • PEP Editorの責任とワークフローについては別途記載されている。

感想

給料ほしいってなりそう。すげぇ。