Last Updated: 2/6/2024, 5:44:57 AM

# PEP ってなに?

機能拡張の際に議論した
結果などが、
まとめられた資料です。

PEP 8 は Python でプログラミングをする人が最初に見る PEP だと思います。 では PEP とは何でしょうか? 簡単に言えば、機能拡張の際に議論した結果などが、まとめられた資料です。 PEP 8 の他にも様々な PEP があります。 ここではいくつかの PEP をピックアップしてみたいと思います。

# PEP 1 - PEP とは何か

PEP の正式名称は Python Enhancement Proposal です。 日本語に無理やり訳せば「Python の機能拡充のための提案」でしょうか。 PEP 1 に PEP とは何かの説明があるので、引用してみたいと思います。 以下、一部抜粋したものを示します。

PEP って何? - PEP Purpose and Guidelines PEP 1 (opens new window)
PEP 1 - What is a PEP? - PEP Purpose and Guidelines

PEP stands for Python Enhancement Proposal.
PEP は Python Enhancement Proposal (Python 拡充提案)を意味しています。

PEP は設計書です。この設計書は Python コミュニティに情報を提供したり、 Python の新しい機能、手続き、または環境を説明したりするものです。
A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment.

PEP は、機能に関する簡潔な技術仕様と、その機能の動作原理を伝えなければなりません。
The PEP should provide a concise technical specification of the feature and a rationale for the feature.

PEP が主要な仕組みとなることを意図しています。どのような仕組みかと言えば、 大きな新しい機能の提案をするため、議案に対してコミュニティに提供された情報を取り纏めるため、 Python に取り入れられた設計に関する決定を文書にするための物です。
We intend PEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python.

PEP の起草者は、コミュニティ内でコンセンサスを確立することと、反対意見を文書化することに責任を持ちます。
The PEP author is responsible for building consensus within the community and documenting dissenting opinions.

PEP はバージョン管理されたリポジトリでテキストファイルとして保存されるため、 これらの改訂履歴は過去になされた機能提案 PEP の変更履歴のレコードとなります。[1]。
Because the PEPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal [1].

[1] 変更履歴のレコードは、古いバージョンを取得するための通常の git コマンドを使えば閲覧できます。 また https://github.com/python/peps からHTTP 経由でも、閲覧することができます。
[1] This historical record is available by the normal git commands for retrieving older revisions, and can also be browsed via HTTP here: https://github.com/python/peps

PEP 1 では、この他にも PEP の採択プロセスなどが記載されています。 読んだことありませんが。

問題

PEP の正式名称は何ですか?

# PEP の位置付け

PEP の位置付けは、提案書 Proposal です。

Python の仕様 Specification が、必ずしも全て PEP に記述されている訳ではないことに留意してください。 なおドキュメント Document は、動作をわかりやすく噛み砕いたもので(僕には難しいですが)、仕様が網羅されているわけではありません。

仕様 Specification が網羅されていないと、どのような問題が起こるのでしょうか。 以下の記事は PyPy を実装するにあたり、 Python には仕様 Specification がないから CPython の細かい動作、実装を模倣する必要があり面倒だと Flask の作者である Armin Ronacher 氏が意見している記事です。

文書 Document、仕様 Specification、実装 Implementation の3つを区別すると良いかなと思いました。

# PEP 8 - Python のコーディング規約

PEP 8 ってなに? では PEP 8 を、 1 行はなんで 79 文字以内なの? では PEP 7 を そして docstring ってなに? では PEP 257 を見てきました。

PEP 7, PEP 257 など、かなり話は脱線しましたが、 これでやっと PEP 8 の冒頭の文章につながりました笑 PEP 8 が、どういう性格の文章なのか雰囲気が伝わると嬉しいです。

はじめに
この文書は Python の標準ライブラリに含まれている Python コードのコーディング規約です。

CPython に含まれる C 言語のコード [1] については、 対応する  C 言語のスタイルガイドを記した PEP  を参照してください。 この文書と  PEP 257 (Docstring 規約)  は、Guido が書いたオリジナルの Python スタイルガイドのエッセイと、 Barry のスタイルガイドに少し追記したものをまとめたものです。 [2]

問題

Python で書かれた標準ライブラリのコーディング規約を定めたものは、どれですか?

# PEP 3105 - print を関数にする

「コーディング規約」の PEP ばかり紹介してしまったので、 すこし毛並みの違う、ちょっとだけ「文法」に関する PEP をご紹介します。 この PEP は何を提案しているのでしょうか?

Python 2 では print は でした。 例えば return, assert, del などは に分類されます。

# Python 2
# 文
print 'Hello, world!'

文の反対は です。 四則演算や関数, メソッドの呼び出しは、 に分類されます。

# 式
#   四則演算
1 + 1  # 2

#   関数
sorted([3, 2, 0, 1])  # [0, 1, 2, 3]

# ◯ Python のコードの分類

Python のコードは、大きく分けて次の3つに分けることができます。

  1. 式 ... 値が返されます。
  2. 文 ... 純粋な制御構文
  3. コメント ... 何もしない。

# ◯ 文と式の違い

式は値を返しますが、文は値を返しません。 例えばリストの sorted メソッドは、 パッと見ると値を返していないように見えますが、 正確には None を返しています。

# 式 値を返す     -> 変数に代入できる。
a = [3, 0, 2, 1].sort()

# 文 値を返さない -> 変数に代入できない。(SyntaxError)
b = del a
>>> a = [3, 0, 2, 1].sort()
>>> 
>>> b = del a
  File "<stdin>", line 2
    b = del a
          ^
SyntaxError: invalid syntax
>>>

# ◯ 文と関数の違い

関数は括弧 ( ) を必要としますが、 文は括弧 ( ) を必要としません。

s = 'Hello, world!'

# 関数 括弧 ( ) が必要(SyntaxError)
print s

# 文   括弧 ( ) は不要
del s
>>> s = 'Hello, world!'
>>>
>>> print s
  File "<stdin>", line 2
    print s
          ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(s)?
>>> 
>>> del s
>>> 

そんなこんなで文と式(関数)は、異なるものです。 そして print という処理を文から関数にしたことで Python 2 と Python 3 は、後方互換性を失いました。

もちろん、他にも多くの後方互換性を失う変更が行われました。 例えば Python 2 では int 型とは別に long 型がありました。 Python 3 では統一されて int 型だけになりました。

いずれにせよ print を文から関数にしたのは、 大きな変更に間違いありません。 Python 2 から 3 にかけて後方互換性を切りました。

しかし、たかだか書き方を変えるためだけに 後方互換性を切る必要性はあったのでしょうか? 後方互換性を切るというのは、それまで書いてきたコードが動かなくなるので、 とても、とても大きな変更です。

# Python 2
print 'Hello, world!'
# Python 3
print('Hello, world!')

PEP 3105 には、後方互換性を切り捨ててまで print 文を廃止して print 関数に移行したか、その経緯がまとめられています。 理由は print が文である必要がないからです。 文でなければならないものにだけ文が使われます。

文でなければならない理由ってなんだ?って感じです。 具体例として assert と del が文である理由を見ると理解が速いかなと思います。

# PEP 328 - 相対 import

import 文の記事を書くにあたり PEP 328 の和訳をしました。 全然読まなくても大丈夫な文章です。 もしご興味があれば PEP の文章の雰囲気は伝わるかなと思います。 読みやすい文法について議論している雰囲気があって、ほんの少しですが面白いです。

# PEP 0 - PEP の一覧

PEP 0 でカテゴリ分けされいます。 例えば PEP 8 は Meta-PEPs に PEP 20 は Other Informational PEPs に分類されています。 PEP を概観するには、ちょうどいいかなと思います。

PEP 0 -- Index of Python Enhancement Proposals (PEPs) (opens new window)

  • Meta-PEPs (PEPs about PEPs or Processes)
  • Other Informational PEPs
  • Provisional PEPs (provisionally accepted; ...)
  • Accepted PEPs (accepted; may not be implemented yet)
  • Open PEPs (under consideration)
  • Finished PEPs (done, with a stable interface)
  • Historical Meta-PEPs and Informational PEPs
  • Deferred PEPs (postponed pending further research ...)
  • Abandoned, Withdrawn, and Rejected PEPs