PEP와 숫자로 이루어진 수많은 python proposal이 존재하지만, 그 많은 proposal들은 어떤 기준으로 읽어야 하고, 판단을 해야 할까? 어떤 proposal을 읽어야 하고 어떤 proposal을 읽지 않아도 될까? 이런 질문에 대한 답을 공교롭게도 PEP의 1번 문서가 설명해준다. 그래서 PEP 1번 문서를 간단하게 리뷰해본다.

What is a PEP?

PEP가 뭔지 위해 PEP의 1번 문서를 살펴보면 가장 첫 소제목으로 나와있다. 해당 섹션의 첫번째 문단을 가져와보자.

PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python or its processes or environment. The PEP should provide a concise technical specification of the feature and a rationale for the feature.

즉, Python Enhancement Proposal의 약어로, Python 커뮤니티로의 정보전달을 위한 일종의 설계 문서가 될 수도 있고, 파이썬의 새로운 기능을 설명하는 문서가 될 수도 있다. 따라서 PEP는 정확한 기술적인 명세가 들어가야하고 그 기능이 필요한 이유 또한 필요하다. 또한 PEP 문서는 텍스트 파일로 관리하므로, versioned repository, 즉 GitHub에 저장된다.

PEP Audience

그럼 누가 이 PEP문서를 읽을까? 주로 이 PEP문서를 읽는, 읽어야 하는 사람은 CPython 코어 개발자, 코어 개발자들이 선출한 Steering Council, 그리고 CPython이 아닌 다른 Python 구현체를 만드는 사람들이다. 그 외에도 Python 커뮤니티에서 Informatinal PEP와 같은 형태로 앞으로의 API Convention이나, 복잡한 설계를 합의하기 위해 사용할 수도 있다.

PEP Types

PEP는 세가지 종류가 있다.

• Standards Track PEP는 새로운 기능 혹은 구현을 설명하기 위한 PEP문서이다. 이후에 표준 라이브러리로 추가될 기능이지만 현재는 서드파티로 지원되는 기능에 대한 interoperability를 기술할 수도 있다.
• Informational PEP는 Python의 설계 이슈 혹은 일반적인 가이드와 정보를 Python 커뮤니티에 전달하기 위해 작성하는 PEP문서이다. 하지만 사용자와 Python 개발자는 꼭 이 PEP문서를 따를 필요는 없고, 조언 정도로 생각하면 된다.
• Process PEP는 Python과 관련된 프로세스를 기술하거나, 해당 프로세스에 대한 변경을 제안하는 PEP문서이다. Standards Track PEP와 비슷하게 보일 수 있지만, 이 PEP 문서는 Python언어 그 자체에 대한 것은 아니다. 하지만 이 문서는 Informational PEP와는 다르게 커뮤니티의 합의가 필요한 문서이다. 즉, 사용자는 이 Process PEP를 마냥 무시할 수 있는 것이 아니다. Meta-PEP의 목록이 Process PEP에 속한다.

PEP Workflow

Python’s Steering Council

PEP가 최종적으로 accept 될 지, reject 될 지 정하는 사람들이다. PEP 13에 자세히 설명되어 있다.

Python’s Core Developers

Python’s Core Developers는 Python core team 멤버들을 말하며, 이들 역시 PEP 13에 자세히 설명되어 있다.

Python’s BDFL

BDFL은 Benevolent dictator for life를 말하며 한국어로는 대부분 “자비로운 종신 독재자”정도로 번역되었다. 그 유명한 파이썬의 창시자인 Guido van Rossum을 일컫는 말이 맞지만, Guido van Rossum은 PEP 572가 끝나면서 BDFL에서 물러났으므로 BDFL-Delegate는 historical reference 정도이다.

PEP Editors

PEP Editor들은 PEP 숫자를 지정하거나 PEP status를 바꾸는 등의 PEP Workflow에 대해서 책임이 있는 사람이다. editorship은 editor들의 초대로 이루어진다.

Start with an idea for Python

위는 PEP 수정, 작성에 참여하는 사람, 조직들이고, 이제서야 PEP 작성에 대한 내용이 시작한다.

PEP 작성은 Python에 대한 새로운 아이디어로부터 시작하며, Single key proposal이나 new idea만을 포함하길 추천한다고 한다. 엄청 작은 enhancement들은 PEP로 작성할 필요가 없으며 Python Issue Tracker만으로도 충분하다고 한다. 만약 작성한 PEP가 너무 광범위하거나 제대로 기술되지 않는다면 PEP Editor들은 이를 reject할 수도 있다.

각 PEP는 Champion이 필요하다. 지금부터 설명할 스타일과 포맷으로 PEP를 작성하고, 적절하게 토론이 이루어지도록 유도하며, 아이디어를 커뮤니티에서 잘 합의하도록 하는 사람이 Champion(a.k.a. Author)이다. CompLangPython¹(python-list@python.org mailing list)에 포스팅하는 것이 그 방법 중 하나다.

꼭 포스팅하는 것을 권장하는 까닭은 그 행동이 PEP를 헛되게 작성하지 않도록 도와주기 때문이다. 아이디어 자체가 작성자에게 대단하게 들릴 수도 있지만, 파이썬을 사용하는 많은 사람들에게는 그렇게 좋지 않을 수도 있기 떄문이다. 파이썬은 정말 많은 분야에서 사용되고 있는 것이 사실이고, 많은 좋은 아이디어들이 사실은 특정 분야에서만 좋을 수 있다는 것이다.

Submitting a PEP

한 줄로 간단하게 요약하자면, Draft PEP는 python/peps 레포지토리에 풀 리퀘스트를 작성하는 것으로 할 수 있다.

더 자세하게 설명해보자. 메일링 리스트 등에서 의견을 나누고 난 이후에는 Python Core Developer인지 아닌지에 따라 많은 사항이 달라지게 된다. 공동 작성자 중에 Python Core Developer가 없다면 sponsor를 구해야 한다. sponsor는 PEP 작성자에게 PEP가 진행되는 과정을 알려주는 멘토같은 역할을 수행한다.

그 후에 Draft PEP를 작성할 수 있는데, 자세한 규칙은 해당 절을 자세히 읽어보도록 하자.

번호가 할당된 PEP에 approve가 나면 (PEP Accept가 아니다) master브랜치에 머지된다. PEP는 이유없이 거부되지 않는데 대표적인 사례는 아래와 같다.

• duplication of effort
• being technically unsound
• not providing proper motivation or addressing backwards compatibility
• not in keeping with the Python philosophy.

PEP Review & Resolution

PEP는 한번 master에 들어가고 나면 많은 stage를 거치게 되는데, 아래 이미지가 제일 잘 그려진 이미지라고 생각한다.

핵심만 말해보자면, PEP는 accept 상태가 되기 위해 몇몇 기준을 만족해야 한다.

• The enhancement must represent a net improvement.
• The proposed implementation, if applicable, must be solid and must not complicate the interpreter unduly.
• A proposed enhancement must be “pythonic” in order to be accepted by the Steering Council.

하지만 위 기준은 일반적인 PEP의 기준으로 Standard library에 accept되기 위해서는 별도의 PEP2 기준을 만족해야 한다.

PEP가 Accept되고 난 후에는 구현이 완성되어야 한다. 이 구현은 reference implementation이란 단어를 쓴다. reference implementation이 완성되고 나면 Final로 status가 변하게 된다.

특수한 Provision status가 있는데 이는 추가적인 디자인이나 인터페이스 피드백을 받기 위한 상태이다. 왜 추가적인 디자인/인터페이스 피드백이 필요하냐면 언어 자체의 기능이나 standard library API일 경우 long term stability를 중시하기 때문이다. Provision은 Provisionally Accepted의 줄임말이다. 완성이 된다면 Final status로 간다. 물론 Provisionally Accept된 PEP들도 Reject될 수 있다.

PEP Maintenance

Standard Track PEP는 대부분 Final Status에 들어가고 난 이후에는 수정이 되지 않는다. 이 PEP들은 Final이 되고 나서는 expected behavior에 대한 formal documentation이 된다.

Informational, Process PEP는 시간에 따라 계속 수정된다. 디테일한 사항들이 추가되고, 더 정확한 Practice로 변하게 된다.

…

중간에 PEP 파일 포맷도 존재하는데, 이건 건너뛸게요.

하지만 그 중에 What belongs in a successful PEP?는 정말 읽을 만한 챕터입니다.

…

Reporting PEP Bugs, or Submitting PEP Updates

PEP bug report의 가장 좋은 방법은 draft 상태일 경우에는 comment를 달아주는 것이다. 더 진행된 PEP의 경우에는 GitHub Issue를 이용하거나 Pull Request를 작성하는 방법이 가장 좋다.

이 이후 내용은 그렇게 중요하지 않은 내용이라 생각되어 건너뜁니다.

—

Python의 TMI를 쉽게 읽을 수 있는 좋은 문서들이 많이 있는데, 그 중 PEP0001 문서는 가장 쉽게 읽을 수 있는 문서 중 하나라고 생각한다. 실제로 도움이 될 만한 내용을 많이 담고 있다. 또한 파이썬이 어떤 철학을 가지고 있고, 어떻게 나아가고자 하는지에 대해 생각해볼 수 있다. 그래서 파이썬을 제대로 사용하는/사용하고픈 사람이라면 다른 수많은 PEP 문서들도 중요하지만, PEP0001이 필독이 아닌가 싶다.