PEP 1 – PEP의 목적과 지침

Author:

Barry Warsaw, Jeremy Hylton, David Goodger, Alyssa Coghlan

Status:

Active

Type:

Process

Created:

13-Jun-2000

Post-History:

21-Mar-2001, 29-Jul-2002, 03-May-2003, 05-May-2012, 07-Apr-2013

---

Table of Contents

• PEP란 무엇입니까?
• PEP의 대상 독자
• PEP의 유형
• PEP 워크플로
  • Python 운영 위원회
  • Python 코어 개발자
  • Python의 BDFL
  • PEP 편집자
  • Python에 대한 아이디어로 시작하기
  • PEP 제출하기
  • PEP 논의하기
  • PEP 검토 및 결정
  • PEP 유지 관리
• 성공적인 PEP에는 무엇이 들어가야 합니까?
• PEP 형식과 템플릿
• PEP 헤더 전문
• 보조 파일
• 기존 PEP 변경하기
• PEP 소유권 이전하기
• PEP 편집자의 책임과 워크플로
• 각주
• 변경 이력
• Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

PEP란 무엇입니까?

PEP는 Python Enhancement Proposal(파이썬 개선 제안)의 약자입니다. PEP은 Python 커뮤니티에 정보를 제공하거나 Python 또는 그 프로세스나 환경의 새로운 기능을 설명하는 설계 문서입니다. PEP는 해당 기능의 간결한 기술 명세와 그 기능의 근거를 제시해야 합니다.

PEP은 주요 새 기능을 제안하고, 어떤 사안에 대해 커뮤니티의 의견을 수렴하며, Python에 반영된 설계 결정을 문서화하는 주된 수단이 되는 것을 목표로 합니다. PEP 작성자는 커뮤니티 내에서 합의를 이끌어 내고 반대 의견을 문서화할 책임이 있습니다.

PEP는 버전 관리되는 저장소에 텍스트 파일로 유지되므로, 그 개정 이력이 곧 기능 제안의 역사적 기록이 됩니다. 이 역사적 기록은 이전 개정판을 가져오는 일반적인 git 명령으로 확인할 수 있으며, GitHub에서도 둘러볼 수 있습니다.

PEP의 대상 독자

PEP의 일반적인 주요 독자는 CPython 참조 인터프리터의 코어 개발자와 그들이 선출한 운영 위원회, 그리고 Python 언어 명세의 다른 구현을 개발하는 개발자입니다.

그러나 Python 커뮤니티의 다른 부분에서도 예상되는 API 관례를 문서화하고 여러 프로젝트 간의 협업이 필요한 복잡한 설계 조율 문제를 관리하기 위해 이 프로세스를 사용할 수 있습니다(특히 Informational PEP의 경우).

PEP의 유형

PEP에는 세 가지 종류가 있습니다:

1. Standards Track PEP은 Python의 새로운 기능이나 구현을 설명합니다. 또한 향후 버전에서 후속 PEP이 표준 라이브러리 지원을 추가하기 전에, 현재 Python 버전에서는 표준 라이브러리 밖에서 지원될 상호 운용성 표준을 설명할 수도 있습니다.
2. Informational PEP은 Python 설계 문제를 설명하거나 Python 커뮤니티에 일반적인 지침이나 정보를 제공하지만, 새로운 기능을 제안하지는 않습니다. Informational PEP이 반드시 Python 커뮤니티의 합의나 권고를 나타내는 것은 아니므로, 사용자와 구현자는 Informational PEP을 무시하거나 그 조언을 따를 수 있습니다.
3. Process PEP은 Python을 둘러싼 프로세스를 설명하거나, 프로세스의 변경(또는 프로세스 내의 이벤트)을 제안합니다. Process PEP은 Standards Track PEP과 비슷하지만 Python 언어 자체가 아닌 다른 영역에 적용됩니다. Process PEP은 구현을 제안할 수 있지만 Python 코드베이스에 대한 구현은 제안하지 않습니다. 커뮤니티의 합의가 필요한 경우가 많으며, Informational PEP과 달리 단순한 권고 이상이므로 사용자는 일반적으로 이를 무시할 수 없습니다. 예로는 절차, 지침, 의사 결정 프로세스의 변경, Python 개발에 사용되는 도구나 환경의 변경 등이 있습니다. 모든 메타 PEP 역시 프로세스 PEP로 간주됩니다.

PEP 워크플로

Python 운영 위원회

이 PEP에는 “운영 위원회(Steering Council)” 또는 “위원회(Council)”라는 표현이 여러 번 등장합니다. 이는 PEP 13에 설명된, 선출된 운영 위원회의 현재 구성원을 가리키며, 이들은 PEP의 수락 또는 거부 여부를 최종적으로 결정하는 권한을 가집니다.

Python 코어 개발자

이 PEP에는 “코어 개발자”라는 표현이 여러 번 등장합니다. 이는 PEP 13에 설명된, 현재 활동 중인 Python 코어 팀 구성원을 가리킵니다.

Python의 BDFL

이 PEP의 이전 버전에서는 PEP 결정권자를 가리켜 “BDFL-Delegate”라는 명칭을 사용했습니다. 이는 Python의 이전 거버넌스 모델을 역사적으로 반영한 것이었습니다. 이 모델에서는 모든 설계 권한이 궁극적으로 Python 프로그래밍 언어를 처음 만든 Guido van Rossum에게서 나왔습니다. 이와 달리 운영 위원회(Steering Council)의 설계 권한은 현재 활동 중인 코어 개발자들이 위원회를 선출했다는 데서 나옵니다. 현재는 BDFL-Delegate 대신 PEP-Delegate라는 명칭을 사용합니다.

PEP 편집자

PEP 편집자는 PEP 워크플로의 행정적·편집적 측면(예: PEP 번호 부여 및 상태 변경)을 관리하는 책임을 맡은 사람들입니다. 자세한 내용은 PEP Editor Responsibilities & Workflow를 참조하십시오.

PEP 편집자는 현재 편집자들의 초대로 임명되며, GitHub에서 @python/pep-editors를 멘션하여 연락할 수 있습니다. 모든 PEP 워크플로는 GitHub PEP repository의 이슈와 풀 리퀘스트를 통해 진행할 수 있습니다.

Python에 대한 아이디어로 시작하기

PEP 절차는 Python에 대한 새로운 아이디어에서 시작합니다. 하나의 PEP에는 하나의 핵심 제안이나 새로운 아이디어만 담을 것을 강력히 권장합니다. PEP의 초점이 좁을수록 성공할 가능성이 높아지는 경향이 있습니다. 대부분의 개선 사항과 버그 수정에는 PEP가 필요하지 않으며, Python issue tracker에 바로 제출할 수 있습니다. PEP 편집자는 PEP 제안의 초점이 너무 흐리거나 범위가 너무 넓어 보이면 이를 거부할 권리를 가집니다. 확신이 서지 않으면 PEP를 초점이 명확한 여러 개의 PEP로 나누십시오.

모든 PEP에는 챔피언이 있어야 합니다. 챔피언은 아래에 설명된 스타일과 형식에 따라 PEP를 작성하고, 적절한 포럼에서 논의를 이끌며, 해당 아이디어에 대한 커뮤니티의 합의를 이끌어 내려고 노력하는 사람입니다. PEP 챔피언(즉, 작성자)은 먼저 해당 아이디어가 PEP로 만들 만한지 확인해야 합니다. 보통은 Python Discourse의 Ideas category에 글을 올리는 것이 가장 좋은 방법입니다. 다만 Python Discourse의 Typing category(정적 타이핑 관련 아이디어)나 Packaging category(패키징 관련 아이디어)처럼 더 전문적인 곳이 적절한 경우에는 그곳을 이용하십시오.

PEP를 작성하는 단계까지 가기 전에 아이디어를 공개적으로 검증하는 것은 잠재적인 저자의 시간을 아끼기 위한 것입니다. 지금까지 Python을 변경하자는 많은 아이디어가 제안되었지만 여러 가지 이유로 거부되었습니다. 아이디어가 독창적인지 Python 커뮤니티에 먼저 물어보면, 이전 논의에 비추어 거부될 것이 확실한 일에 너무 많은 시간을 쏟는 것을 막을 수 있습니다(인터넷 검색만으로 항상 알 수 있는 것은 아닙니다). 또한 해당 아이디어가 저자에게만이 아니라 커뮤니티 전체에 적용될 수 있는지 확인하는 데에도 도움이 됩니다. 저자에게 좋아 보이는 아이디어라고 해서 Python이 사용되는 대부분의 분야에서 대부분의 사람들에게 효과가 있다는 뜻은 아닙니다.

챔피언이 아이디어가 채택될 가능성이 있는지 Python 커뮤니티에 물어본 뒤에는, 앞에서 언급한 적절한 곳에 PEP 초안을 제출해야 합니다. 이를 통해 저자는 PEP 초안을 구체화하여 형식을 제대로 갖추고 품질을 높이며, 제안에 대한 초기 우려 사항을 해결할 기회를 얻습니다.

PEP 제출하기

위의 초기 논의를 마친 뒤의 워크플로는 PEP 공동 저자 중에 코어 개발자가 있는지에 따라 달라집니다. PEP 공동 저자 중 한 명 이상이 코어 개발자라면, 그들이 아래에 설명된 절차를 따를 책임을 집니다. 그렇지 않은 경우(즉, 공동 작성자 중 코어 개발자가 아무도 없는 경우), PEP 작성자는 PEP의 후원자를 찾아야 합니다.

코어 개발자 후원자를 찾는 것이 가장 바람직하지만, 운영 위원회의 승인을 받으면 코어 개발자가 아닌 후원자를 선정할 수도 있습니다. GitHub “PEP editors” 팀의 구성원과 타이핑 위원회(Typing Council, PEP 729)의 구성원은 스폰서로 사전 승인되어 있습니다. 후원자의 역할은 PEP 작성자가 PEP 프로세스의 실무 절차를 잘 밟아 나갈 수 있도록 안내하는 것입니다(일종의 멘토 역할). 스폰서가 된다고 해서 나중에 공동 저자나 PEP 위임자(PEP-Delegate)가 될 자격을 잃는 것은 아닙니다(단, 둘 다 될 수는 없습니다). PEP의 스폰서는 헤더의 “Sponsor:” 필드에 기록됩니다.

후원자나 PEP을 공동 작성하는 코어 개발자가 PEP이 제출할 준비가 되었다고 판단하면, 제안서를 GitHub pull request를 통해 초안 PEP으로 제출해야 합니다. 초안은 아래에 설명된 PEP 스타일로 작성해야 하며, 그렇지 않으면 즉시 검토에서 탈락합니다(다만 사소한 오류는 편집자가 수정할 수도 있습니다).

표준 PEP 워크플로는 다음과 같습니다.

• PEP 작성자인 여러분은 PEP repository를 포크하고, 새 PEP을 담은 pep-NNNN.rst라는 이름의 파일을 만듭니다. NNNN은 게시되었거나 PR로 올라와 있는 PEP이 사용하지 않는, 다음으로 사용 가능한 PEP 번호여야 합니다.
• “PEP:” 헤더 필드에는 파일 이름과 일치하는 PEP 번호를 초안 PEP 번호로 입력하십시오.
• “Type:” 헤더 필드에는 상황에 맞게 “Standards Track”, “Informational”, “Process” 중 하나를 입력하고, “Status:” 필드에는 “Draft”를 입력하십시오. 자세한 내용은 PEP Header Preamble을 참고하십시오.
• PEP repository에 쓰기 권한이 있는 공동 저자나 스폰서가 새 파일의 담당자로 등록되도록 .github/CODEOWNERS를 업데이트하십시오. 이렇게 하면 앞으로 이 파일을 변경하는 풀 리퀘스트가 모두 그들에게 할당됩니다.
• 이를 여러분의 GitHub 포크에 푸시하고 풀 리퀘스트를 제출하십시오.
• PEP 편집자는 PR의 구조, 서식 및 기타 오류를 검토합니다. reST 형식의 PEP에는 PEP 12가 템플릿으로 제공됩니다. 이 문서는 PEP에서 사용하는 reST 마크업에 대한 완전한 입문 내용도 제공합니다. 승인 기준은 다음과 같습니다:
  • 내용이 타당하고 완전해야 합니다. 아이디어가 기술적으로 타당해야 합니다. 편집자는 제안이 수락될 가능성이 있어 보이는지는 고려하지 않습니다.
  • 제목이 내용을 정확하게 설명해야 합니다.
  • PEP의 언어(맞춤법, 문법, 문장 구조 등)와 코드 스타일(예제는 PEP 7 및 PEP 8을 따라야 합니다)은 올바르고 규칙에 맞아야 합니다. 풀 리퀘스트가 제출되면 PEP 본문이 올바른 reStructuredText 형식인지 자동으로 검사합니다. 유효하지 않은 reST 마크업이 있는 PEP는 승인되지 않습니다.

  편집자는 문제가 검토 과정에서 수정될 것으로 기대하므로 이 초기 검토에서는 대체로 상당히 관대합니다. 참고: PEP가 승인되었다고 해서 민망한 실수가 없다는 보장은 되지 않습니다! 정확성은 편집자가 아니라 저자와 검토자가 책임집니다.

  PEP가 승인될 준비가 되지 않았다면, 편집자는 구체적인 지침과 함께 PEP를 저자에게 돌려보내 수정하도록 합니다.

• 승인되면 편집자가 여러분의 PEP에 번호를 부여합니다.

검토 과정이 끝나고 PEP 편집자가 PEP를 승인하면(이것은 PEP를 수락하는 것과 같지 않다는 점에 유의하십시오!), 편집자가 여러분의 풀 리퀘스트를 main에 스쿼시 커밋합니다.

PEP 편집자는 부당하게 PEP 게시를 거부하지 않습니다. PEP 지위를 거부하는 사유에는 노력의 중복, 기술적 결함, 적절한 동기를 제시하지 않거나 하위 호환성을 다루지 않은 경우, 또는 Python 철학에 부합하지 않는 경우 등이 있습니다. 승인 단계에서는 운영 위원회(Steering Council)에 자문을 구할 수 있으며, 운영 위원회는 초안이 PEP로 적합한지에 대한 최종 결정권자입니다.

PEP repository에 쓰기 권한이 있는 개발자는 새 PEP를 작성하고 커밋하여 PEP 번호를 직접 확보할 수 있습니다. 이 경우 해당 개발자는 일반적으로 PEP 편집자가 처리하는 작업을 직접 처리해야 합니다(PEP Editor Responsibilities & Workflow 참조). 여기에는 초기 버전이 PEP 제출에 기대되는 기준을 충족하는지 확인하는 일도 포함됩니다. 또는, 개발자라도 풀 리퀘스트를 통해 PEP를 제출해야 합니다. 이 경우 일반적으로 절차를 직접 처리해야 합니다. PEP 편집자의 도움이 필요하면 GitHub에서 @python/pep-editors를 멘션하십시오.

업데이트가 필요할 때, PEP 작성자 본인(또는 협업하는 개발자)이 PEP repository에 쓰기 권한이 있다면 새 버전을 직접 체크인할 수 있습니다. PEP 번호를 일찍 할당받으면 참조하기 쉬워 유용할 수 있으며, 특히 여러 PEP 초안이 동시에 검토되고 있을 때 그렇습니다.

표준 트랙 PEP는 설계 문서와 참조 구현의 두 부분으로 구성됩니다. 원칙적으로는 좋아 보이는 아이디어도 실제로 구현해 보면 비현실적인 것으로 드러나는 경우가 있으므로, 일반적으로 적어도 프로토타입 구현은 PEP와 함께 개발할 것을 권장합니다.

PEP 논의하기

PEP 번호가 할당되고 PEP 초안이 PEP repository에 커밋되는 즉시, PEP의 내용을 논의하고 검토할 중심 장소를 마련하기 위해 해당 PEP의 논의 스레드를 만들어야 하며, Discussions-To 헤더가 그 스레드로 연결되도록 PEP를 업데이트해야 합니다.

PEP 작성자(해당하는 경우 후원자)는 다음 기준을 충족하는 한 논의를 위한 합리적인 장소를 자유롭게 선택할 수 있습니다.

• 포럼이 PEP의 주제에 적합해야 합니다.
• 관심 있는 모든 당사자가 참여할 수 있도록 스레드가 웹에 공개되어 있어야 합니다.
• 논의에는 파이썬 커뮤니티 행동 강령이 적용되어야 합니다.
• PEP의 Discussions-To 헤더에 현재 논의 스레드로 연결되는 직접 링크가 제공되어야 합니다.

대부분의 새 PEP에는 Python Discourse의 PEPs category가 선호되며, 과거에는 Python-Dev 메일링 리스트가 흔히 사용되었습니다. 일부 전문 주제에는 전용 장소가 있습니다. 예를 들어 타이핑 PEP와 패키징 PEP에는 각각 Python Discourse의 Typing category와 Packaging category가 있습니다. PEP 작성자가 가장 적합한 장소를 확신하지 못하는 경우, PEP 후원자와 PEP 편집자가 그에 맞게 조언할 수 있습니다.

PEP가 대폭 재작성되거나 제안된 명세에 그 밖의 중대하고 실질적인 변경이 생기면, 추가 피드백을 받기 위해 일반적으로 선택한 장소에 새 스레드를 만들어야 합니다. 이 경우 Discussions-To 링크를 업데이트하고, 이 새 스레드를 가리키는 Post-History 항목을 새로 추가해야 합니다.

PEPs category가 논의 장소로 선택되지 않았다면, PEP 초안이 저장소에 커밋될 때와 새 스레드를 만들어야 할 만큼 중대한 변경이 있을 때 렌더링된 PEP와 Discussions-To 스레드로 연결되는 링크를 최소한 포함한 간단한 공지 글을 PEPs category에 올려야 합니다.

PEP 작성자는 검토를 위해 PEP를 제출하기 전에 커뮤니티 피드백을 수집할 책임이 있습니다. 다만 장황하고 끝이 없는 논의를 피하려면, 초기 설계 단계에서 비공개로 또는 범위를 좁혀 피드백을 구하거나, PEP 주제에 전문성을 갖춘 다른 커뮤니티 구성원과 협업하거나, (해당하는 경우) PEP 주제에 맞게 적절히 특화된 논의 장소를 선택하는 등의 전략을 고려해야 합니다. 이 부분은 PEP 작성자가 재량껏 판단해야 합니다.

PEP에 번호가 할당되고 PEP 저장소에 커밋되면, 실질적인 사안은 일반적으로 비공개 채널, GitHub 풀 리퀘스트 리뷰 또는 관련 없는 장소가 아니라 공식 공개 스레드에서 논의해야 합니다. 이렇게 하면 모든 사람이 논의를 따라가고 기여할 수 있으며, 논의가 분산되는 것을 막고, 해당 논의가 PEP 검토 과정의 일부로 충분히 고려되도록 보장할 수 있습니다. 이 지정된 스레드에 올라온 의견, 지지, 우려 및 기타 피드백은 운영 위원회나 PEP 위임자(PEP-Delegate)가 PEP를 검토할 때 고려하는 핵심 요소입니다.

PEP 검토 및 결정

저자들이 PEP를 완성하고 나면 PEP 편집자들에게 스타일과 일관성에 대한 검토를 요청할 수 있습니다. 그러나 PEP의 내용 검토와 채택은 궁극적으로 운영 위원회(Steering Council)가 책임집니다. 이 절차는 저자들(그리고 후원자가 있다면 후원자)이 PEP가 최종 검토와 결정을 받을 준비가 되었다고 판단했을 때 Steering Council issue를 열어 공식적으로 시작합니다.

특정한 경우(예: 변경이 명백히 유익하고 수락될 준비가 되었지만 PEP이 아직 정식으로 검토 제출되지 않은 경우)에는 프로세스를 신속히 진행하기 위해 운영 위원회가 PEP 검토를 시작할 수도 있으며, 이때 먼저 PEP 작성자에게 알리고 수정할 기회를 줍니다.

PEP 승인의 최종 권한은 운영 위원회에 있습니다. 그러나 새 PEP가 제출될 때마다, 해당 PEP에 대해 최종 결정을 내릴 만큼 충분한 경험이 있다고 생각하는 코어 개발자는 누구든지 자신의 의사를 운영 위원회에 알려 그 PEP의 PEP-Delegate 역할을 맡겠다고 제안할 수 있습니다. 운영 위원회가 그 제안을 승인하면, 해당 PEP-Delegate는 그 PEP를 승인하거나 거부할 권한을 갖게 됩니다. Python 타입 시스템과 관련된 PEP의 경우, 타이핑 위원회(PEP 729)가 운영 위원회에 권고안을 제공합니다. 이러한 권고를 요청하려면 타이핑 위원회 이슈 트래커에 이슈를 여십시오.

“PEP-Delegate”라는 용어는 운영 위원회 거버넌스 모델에서 PEP에 대해 지정된 의사 결정자를 가리키며, 이 사람은 PEP 헤더의 “PEP-Delegate” 필드에 기록됩니다. “BDFL-Delegate”라는 용어는 PEP-Delegate의 폐기된 별칭으로, BDFL이 Python을 이끌던 시절의 유산입니다. 과거 문서에서 “BDFL-Delegate”를 언급하는 경우는 모두 “PEP-Delegate”와 같은 것으로 취급해야 합니다.

자신을 PEP-Delegate로 추천하려는 사람은 해당 PEP의 관련 저자들과 (있는 경우) 후원자에게 알려야 하며, 운영 위원회에 요청을 제출해야 합니다(이는 새 이슈를 통해 할 수 있습니다). 이 책임을 맡은 사람은 언제든지 운영 위원회에 추가 지침을 자유롭게 구할 수 있으며, 다른 코어 개발자들의 조언과 관점도 고려해야 합니다.

운영 위원회는 일반적으로 이러한 자기 추천을 기본적으로 승인하지만, 거절할 수도 있습니다. 운영 위원회가 PEP-Delegate 자기 추천을 거절하는 이유로는 잠재적 이해 상충이 있다고 여겨지는 경우(예: PEP 제출자와 같은 조직에서 일하는 경우)나 단순히 다른 PEP-Delegate 후보가 더 적합하다고 판단하는 경우 등이 있으며, 이에 국한되지 않습니다. 코어 개발자(또는 다른 커뮤니티 구성원)가 특정 PEP의 PEP-Delegate가 적합한지 우려한다면, 운영 위원회에 해당 위임을 검토해 달라고 요청할 수 있습니다.

자원하는 사람이 나서지 않으면, 운영 위원회는 해당 PEP의 PEP-Delegate 역할을 기꺼이 맡을 후보자를 찾기 위해 관련 전문성을 갖춘 코어 개발자(그리고 경우에 따라 다른 Python 커뮤니티 구성원)에게 연락합니다. 적합한 후보자를 찾을 수 없으면, 후보자가 나타날 때까지 해당 PEP는 Deferred(보류)로 표시됩니다.

이전에 임명된 PEP-Delegate는 스스로 물러나거나 위원회로부터 물러나 달라는 요청을 받을 수 있으며, 이 경우 새 PEP와 같은 방식으로 새 PEP-Delegate가 임명됩니다(적합한 후임자를 찾을 수 없으면 PEP를 보류하는 것도 포함합니다). PEP-Delegate가 물러나 달라는 요청을 받은 경우, 해당 PEP에 대한 이전의 채택 또는 거부 결정은 모두 무효가 되며, PEP는 Draft(초안) 상태로 되돌아갑니다.

이러한 상시 위임을 두는 경우, 운영 위원회는 충분한 공개 기록을 유지합니다. 이 기록은 이후의 위원회, 코어 개발자, 그리고 더 넓은 Python 커뮤니티가 현재 어떤 위임이 있는지, 그 위임을 왜 두었는지, 어떤 상황에서 더 이상 필요하지 않게 될 수 있는지를 이해할 수 있게 합니다.

PEP가 채택되려면 일정한 최소 기준을 충족해야 합니다. PEP는 제안된 개선 사항을 명확하고 완전하게 설명해야 합니다. 개선 사항은 순(net) 개선이어야 합니다. 제안된 구현이 있다면, 그 구현은 견고해야 하며 인터프리터를 지나치게 복잡하게 만들어서는 안 됩니다. 마지막으로, 제안된 개선 사항이 운영 위원회에서 채택되려면 “파이썬다워야(pythonic)” 합니다. (그러나 “파이썬답다”는 부정확한 용어이며, 운영 위원회가 받아들일 수 있는 것이면 무엇이든 파이썬답다고 정의할 수 있습니다. 이 논리는 의도적으로 순환적입니다.) 표준 라이브러리 모듈 채택 기준은 PEP 2를 참고하십시오.

운영 위원회가 달리 승인한 경우를 제외하고, PEP 결정 공표는 Python Discourse의 PEPs category에 게시됩니다.

PEP가 채택되고 나면 참조 구현을 완성해야 합니다. 참조 구현이 완성되어 메인 소스 코드 저장소에 통합되면 상태가 “Final”로 변경됩니다.

언어 기능이나 표준 라이브러리 API의 장기적 안정성을 확약하기 전에 설계와 인터페이스에 대한 추가 피드백을 수집할 수 있도록 PEP를 “Provisional”로 표시할 수도 있습니다. 이는 “Provisionally Accepted(잠정 수락)”의 줄임말로, 제안이 참조 구현에 포함되도록 수락되었지만 전체 설계를 “Final”로 간주하려면 추가 사용자 피드백이 필요함을 나타냅니다. 통상적으로 수락된 PEP와 달리, 잠정 수락된 PEP는 관련 변경 사항이 Python 릴리스에 포함된 후에도 여전히 Rejected 또는 Withdrawn 상태가 될 수 있습니다.

이 상태는 더 넓은 Python 생태계에서 버전 호환성 문제를 일으킬 수 있으므로, 가능하면 제안의 범위를 줄여(예: 일부 기능을 이후 PEP로 미루는 방식으로) “Provisional” 상태에 의존할 필요가 없게 하는 편이 바람직하다고 여겨집니다. PEP 411은 Provisional 상태의 잠재적 사용 사례에 대한 추가 세부 사항을 제공합니다.

PEP에는 “Deferred” 상태가 부여될 수도 있습니다. PEP에 진척이 없을 때 PEP 작성자나 편집자가 PEP에 이 상태를 부여할 수 있습니다. PEP가 보류되면 PEP 편집자가 이를 다시 초안 상태로 되돌릴 수 있습니다.

PEP는 “Rejected” 상태가 될 수도 있습니다. 모든 논의를 마치고 보니 좋은 아이디어가 아니었을 수도 있습니다. 그래도 이 사실을 기록으로 남기는 것은 중요합니다. “Withdrawn” 상태도 이와 비슷합니다. 이는 PEP 작성자 스스로가 해당 PEP가 실제로는 좋지 않은 아이디어라고 판단했거나, 경쟁하는 제안이 더 나은 대안임을 받아들였다는 뜻입니다.

PEP가 Accepted, Rejected 또는 Withdrawn 상태가 되면 PEP를 그에 맞게 갱신해야 합니다. Status 필드를 갱신하는 것에 더해, 최소한 PEP에 대한 결정을 내린 관련 게시물로 바로 연결되는 링크와 함께 Resolution 헤더를 추가해야 합니다.

PEP는 다른 PEP로 대체되어 원래 PEP가 더 이상 쓰이지 않게 될 수도 있습니다. 이는 API 버전 2가 버전 1을 대체할 수 있는 Informational PEP를 위한 것입니다.

PEP 상태가 거칠 수 있는 경로는 다음과 같습니다:

다이어그램에는 나타나 있지 않지만, “Accepted” PEP는 기술적으로는 수락된 후에도 “Rejected”나 “Withdrawn”으로 이동할 수 있습니다. 이는 PEP가 수락되기 전에는 발견되지 않았던 설계상의 근본적인 결함이 구현 과정에서 드러난 경우에만 일어납니다. Provisional PEP과 달리, 이러한 전환은 수락된 제안이 Python 릴리스에 포함되지 않은 경우에만 허용됩니다. 이미 릴리스된 변경은 대신 정규 폐지 절차를 거쳐야 합니다(폐지의 근거를 제시하는 새 PEP이 필요할 수 있습니다).

일부 Informational PEP와 Process PEP는 완료될 의도가 전혀 없는 경우 “Active” 상태를 가질 수도 있습니다. 예: PEP 1 (이 PEP).

PEP 유지 관리

일반적으로 PEP는 Accepted, Final, Rejected 또는 Superseded 상태에 도달한 후에는 더 이상 실질적으로 수정되지 않습니다. 결론이 나면 PEP는 살아 있는 명세가 아니라 역사적 문서로 간주됩니다. 기대되는 동작에 대한 공식 문서는 핵심 기능이라면 Language Reference, 표준 라이브러리 모듈이라면 Library Reference, 패키징이라면 PyPA Specifications와 같이 다른 곳에서 유지 관리해야 합니다.

Standards Track PEP가 Provisional 상태이거나 (SC의 승인을 받아) Accepted 상태인 동안 구현 경험과 사용자 피드백을 바탕으로 변경이 이루어진다면, 해당 PEP가 Final로 표시되는 시점의 구현을 정확하게 기술하도록 그 변경 사항을 PEP에 기록해야 합니다.

Active 상태인 (Informational 및 Process) PEP는 개발 관행의 변화나 기타 세부 사항을 반영하기 위해 시간이 지나면서 갱신될 수 있습니다. 이러한 경우에 따르는 정확한 절차는 해당 PEP의 성격과 목적에 따라 달라집니다.

때때로 Deferred PEP나 심지어 Withdrawn PEP가 대대적인 갱신과 함께 되살아날 수도 있지만, 대개는 그냥 새 PEP를 제안하는 편이 더 낫습니다.

성공적인 PEP에는 무엇이 들어가야 합니까?

각 PEP에는 다음과 같은 부분/섹션이 있어야 합니다:

1. 서문(Preamble) – PEP에 관한 메타데이터를 담은 RFC 2822 형식의 헤더입니다. 여기에는 PEP 번호, 짧은 설명형 제목(최대 44자로 제한), 각 저자의 이름, 선택적으로 각 저자의 연락처 등이 포함됩니다.
2. 초록(Abstract) – 다루고자 하는 기술적 문제를 짧게(약 200단어) 설명합니다.
3. 동기 – Python 언어, 라이브러리 또는 생태계를 변경하려는 PEP에는 동기가 매우 중요합니다. 동기에서는 PEP가 해결하려는 문제를 다루기에 기존 언어 명세가 왜 불충분한지를 명확하게 설명해야 합니다. 여기에는 Python 생태계의 주요 프로젝트로부터 PEP에 대한 지지를 문서화하여 수집하는 것이 포함될 수 있습니다. 동기가 충분하지 않은 PEP 제출은 거절될 수 있습니다.
4. 명세(Specification) – 기술 명세에서는 모든 새로운 언어 기능의 문법과 의미를 기술해야 합니다. 명세는 적어도 현재의 주요 파이썬 플랫폼(CPython, Jython, IronPython, PyPy)에서 서로 경쟁하면서도 상호 운용 가능한 구현을 만들 수 있을 만큼 상세해야 합니다.
5. 근거(Rationale) – 근거는 특정 설계 결정을 내린 이유를 설명하여 명세를 구체화합니다. 근거에서는 검토했던 대안 설계와 관련 작업을 기술해야 합니다. 예를 들어 다른 언어에서 해당 기능을 어떻게 지원하는지 등이 이에 해당합니다.

   근거는 커뮤니티 안에서 합의가 이루어졌다는 증거를 제시하고, 논의 중에 제기된 중요한 반대 의견이나 우려 사항을 다루어야 합니다.

6. 하위 호환성(Backwards Compatibility) – 하위 호환성을 깨뜨리는 모든 PEP에는 그러한 비호환성과 그 심각도를 설명하는 섹션이 반드시 있어야 합니다. PEP는 저자가 이러한 비호환성에 어떻게 대처하자고 제안하는지 반드시 설명해야 합니다. 하위 호환성을 충분히 논하지 않은 PEP 제출은 곧바로 거절될 수 있습니다.
7. 보안 영향(Security Implications) – PEP와 관련하여 보안상 우려가 있다면, PEP 검토자가 이를 확실히 알 수 있도록 해당 우려 사항을 명시적으로 기술해야 합니다.
8. 가르치는 방법(How to Teach This) – 새로운 기능을 추가하거나 언어 동작을 변경하는 PEP라면, 신규 사용자와 숙련된 사용자 모두에게 PEP를 자신의 작업에 적용하는 방법을 어떻게 가르칠지 다루는 섹션을 포함하면 도움이 됩니다.

   이 섹션에는 사용자가 새로운 기능을 도입하거나 언어 변경에 맞춰 코드를 마이그레이션하는 데 도움이 될 핵심 사항과 권장 문서 변경 사항이 포함될 수 있습니다.

9. 참조 구현(Reference Implementation) – 참조 구현은 PEP가 “Final” 상태가 되기 전에 반드시 완성되어야 하지만, PEP가 수락되기 전에 완성될 필요는 없습니다. 코드를 작성하기 전에 명세와 근거에 대해 합의에 도달하는 접근 방식에도 장점이 있지만, API 세부 사항에 관한 여러 논의를 매듭지을 때는 “대략적인 합의와 동작하는 코드(rough consensus and running code)”라는 원칙이 여전히 유용합니다.

   최종 구현에는 테스트 코드와 함께 Python 언어 레퍼런스나 표준 라이브러리 레퍼런스에 적합한 문서가 포함되어야 합니다.

10. 거절된 아이디어(Rejected Ideas) – PEP를 논의하는 동안 수락되지 않는 다양한 아이디어가 제안될 것입니다. 이렇게 거절된 아이디어는 거절된 이유와 함께 기록해야 합니다. 이는 PEP 최종 버전에 이르기까지의 사고 과정을 기록하는 데 도움이 되고, 이후 논의에서 같은 거부된 아이디어가 다시 제기되는 것도 막아 줍니다.

    어떤 면에서 이 섹션은 근거 섹션에서 떨어져 나온 섹션으로, 특정 아이디어를 결국 채택하지 않은 이유에 특별히 초점을 맞춘 것으로 볼 수 있습니다.

11. 미해결 문제(Open Issues) – PEP가 초안 상태인 동안 추가 논의가 필요한 아이디어가 나올 수 있습니다. 그러한 아이디어는 현재 검토 중이지만 아직 구체적인 결론이 나지 않았다는 것을 사람들이 알 수 있도록 기록해야 합니다. 이는 PEP가 심의될 준비를 갖추는 데 필요한 모든 문제를 빠짐없이 해결하는 데 도움이 되고, 사람들이 이전 논의를 되풀이하는 일을 줄여 줍니다.
12. 감사의 말(Acknowledgements) – PEP의 개발, 논의, 초안 작성을 도운 사람들에게 감사를 표하고 그 기여를 밝히거나, 그 밖의 다른 목적에 유용합니다. 이 섹션은 공동 작성자가 아닌 작업 기여자에게 감사를 표하는 데 사용할 수 있습니다.
13. 각주(Footnotes) – PEP에서 인용한 각주 모음이며, 인라인이 아닌 하이퍼링크 대상을 나열하는 곳입니다.

변경 이력(Change History) – PEP가 거쳐 온 주요 변경 사항의 요약으로, 다음을 기반으로 합니다

논의와 피드백. 이 섹션을 PEP의 “변경 로그” 또는 “릴리스 노트”로 생각하십시오. 일반적으로 주요 변경 사항으로 Post-History 헤더를 갱신할 때마다, 같은 DD-MMM-YYYY 형식을 사용하여 최신 항목이 먼저 오는(즉, 시간 역순) 순서로 새 글머리 기호 항목을 추가하고, 변경 사항을 요약하는 하위 글머리 기호를 다십시오. 이 항목을 Post-History 링크와 같은 링크로 연결하는 것도 고려할 수 있습니다. 이는 필수가 아니므로 PEP 작성자의 재량에 맡겨지지만, 이러한 섹션은 PEP를 지켜보는 사람들이 PEP의 발전 과정을 이해하는 데 도움이 될 수 있습니다. 다음은 예시입니다.

15. 저작권/라이선스 – 각각의 새 PEP는 퍼블릭 도메인과 CC0-1.0-Universal의 이중 라이선스로 배포되어야 합니다(예시는 이 PEP를 참조하십시오).

PEP 형식과 템플릿

PEP는 reStructuredText 형식을 사용하는 UTF-8 인코딩 텍스트 파일입니다. reStructuredText는 여전히 읽기 쉬우면서도 풍부한 마크업을 허용하며, 보기 좋고 기능적인 HTML도 만들어 냅니다. PEP 12에는 작성 지침과 PEP 템플릿이 들어 있습니다.

PEP 텍스트 파일은 온라인에서 더 쉽게 읽을 수 있도록 (Sphinx 기반 빌드 시스템을 통해) 자동으로 HTML로 변환됩니다.

PEP 헤더 전문

각 PEP는 RFC 2822 스타일의 헤더 전문으로 시작해야 합니다. 헤더는 다음 순서로 나타나야 합니다. “*”로 표시된 헤더는 선택 사항이며 아래에서 설명합니다. 그 밖의 모든 헤더는 필수입니다.

  PEP: <pep number>
  Title: <pep title>
  Author: <list of authors' names and optionally, email addrs>
* Sponsor: <name of sponsor>
* PEP-Delegate: <PEP delegate's name>
  Discussions-To: <URL of current canonical discussion thread>
  Status: <Draft | Active | Accepted | Provisional | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  Type: <Standards Track | Informational | Process>
* Topic: <Governance | Packaging | Release | Typing>
* Requires: <pep numbers>
  Created: <date created on, in dd-mmm-yyyy format>
* Python-Version: <version number>
  Post-History: <dates, in dd-mmm-yyyy format,
                 inline-linked to PEP discussion threads>
* Replaces: <pep number>
* Superseded-By: <pep number>
* Resolution: <date in dd-mmm-yyyy format, linked to the acceptance/rejection post>

Author 헤더에는 PEP의 모든 작성자/소유자의 이름과, 선택적으로 이메일 주소를 나열합니다. Author 헤더 값의 형식은 다음과 같아야 합니다:

Random J. User <random@example.com>

이는 이메일 주소를 포함하는 경우의 형식이며, 다음과 같이 이름만 적는 형식은:

Random J. User

주소를 제공하지 않는 경우의 형식입니다. 대부분의 PEP 작성자는 실명을 사용하지만, 다른 이름을 선호하고 PEP 관련 논의에서 그 이름을 일관되게 사용한다면 여기에서도 자유롭게 사용하십시오.

작성자가 여러 명이면 RFC 2822 연속 줄 규칙에 따라 각 작성자를 별도의 줄에 적어야 합니다. 스팸 수집기로부터 보호하기 위해 PEP에 적힌 개인 이메일 주소는 가려진다는 점에 유의하십시오.

Sponsor 필드에는 어떤 개발자(코어 개발자이거나 운영 위원회의 승인을 받은 개발자)가 PEP를 후원하는지 기록합니다. PEP 작성자 중 한 명이 코어 개발자라면 후원자가 필요하지 않으므로 이 필드는 생략해야 합니다.

PEP-Delegate 필드는 PEP의 승인 또는 거부에 대한 최종 결정을 내리도록 운영 위원회가 임명한 사람을 기록하는 데 사용합니다.

참고: Resolution 헤더는 Standards Track PEP에만 필요합니다. 이 헤더에는 PEP에 대한 공식 결정(즉, 승인 또는 거부)이 발표된 이메일 메시지나 기타 웹 자료를 가리키는 URL이 들어갑니다.

Discussions-To 헤더는 PEP에 대한 현재의 공식 논의 스레드 URL을 제공합니다. 이메일 목록의 경우, 목록 자체에 대한 mailto: 링크나 하이퍼링크가 아니라 목록 아카이브에 있는 해당 스레드로 바로 연결되는 링크여야 합니다.

Type 헤더는 PEP의 유형을 지정합니다. 유형은 Standards Track, Informational, Process 중 하나입니다.

선택 사항인 Topic 헤더에는 PEP가 속하는 특별 주제가 있다면 그 주제를 나열합니다. 기존 주제는 주제별 색인를 참조하십시오.

Created 헤더에는 PEP에 번호가 부여된 날짜를 기록하고, Post-History에는 PEP의 Discussions-To 스레드 날짜와 해당 URL을 기록합니다. 이때 날짜는 링크 텍스트로, URL은 링크 대상으로 사용합니다. 두 날짜 모두 dd-mmm-yyyy 형식(예: 14-Aug-2001)이어야 합니다.

Standards Track PEP에는 일반적으로 해당 기능이 어떤 Python 버전과 함께 릴리스될지를 나타내는 Python-Version 헤더가 있습니다. Python-Version 헤더가 없는 Standards Track PEP는 상호 운용성 표준을 나타냅니다. 이러한 표준은 처음에는 외부 라이브러리와 도구를 통해 지원되며, 이후 표준 라이브러리에 지원을 추가하는 후속 PEP로 보완될 수 있습니다. Informational PEP와 Process PEP에는 Python-Version 헤더가 필요하지 않습니다.

PEP에는 이 PEP가 의존하는 PEP 번호를 나타내는 Requires 헤더가 있을 수 있습니다.

PEP에는 해당 PEP가 이후 문서로 대체되어 더 이상 유효하지 않음을 나타내는 Superseded-By 헤더가 있을 수도 있습니다. 이 헤더의 값은 현재 문서를 대체하는 PEP의 번호입니다. 새 PEP에는 자신이 대체한 PEP의 번호를 담은 Replaces 헤더가 있어야 합니다.

보조 파일

PEP에는 다이어그램 같은 보조 파일이 포함될 수 있습니다. 이러한 파일의 이름은 pep-XXXX-Y.ext로 지어야 합니다. 여기서 “XXXX”는 PEP 번호, “Y”는 1부터 시작하는 일련번호이며, “ext”는 실제 파일 확장자(예: “png”)로 바꿉니다.

또는 모든 지원 파일을 pep-XXXX라는 하위 디렉터리에 둘 수도 있습니다. 여기서 “XXXX”는 PEP 번호입니다. 하위 디렉터리를 사용하는 경우 파일 이름에는 제약이 없습니다.

기존 PEP 변경하기

Draft 상태의 PEP는 검토와 결정을 위해 운영 위원회(Steering Council)나 PEP-Delegate에게 제출되기 전까지 저자의 재량에 따라 자유롭게 논의하고 수정을 제안할 수 있습니다. 내용에 관한 실질적인 변경은 일반적으로 PEP의 Discussions-To 헤더에 적힌 논의 스레드에서 먼저 제안해야 합니다. 반면 교정과 오류 수정은 GitHub issue나 GitHub pull request로 제출할 수 있습니다. PEP 저장소에 쓰기 권한이 있는 PEP 작성자는 git push나 GitHub PR로 변경 사항을 제출하여 PEP을 직접 갱신할 수 있습니다. 다른 PEP 수정에 관한 안내는 PEP Maintenance 절을 참고하십시오.

자세한 내용은 Contributing Guide를 참고하시고, 확실하지 않을 때는 먼저 PEP 작성자 및/또는 PEP 편집자에게 확인하십시오.

PEP 소유권 이전하기

때로는 PEP의 소유권을 새로운 챔피언에게 이전해야 할 때가 있습니다. 일반적으로 원저자를 이전된 PEP의 공동 저자로 남겨 두는 것이 바람직하지만, 이는 전적으로 원저자가 결정할 일입니다. 소유권을 이전할 좋은 이유로는 원저자가 더 이상 PEP를 업데이트하거나 PEP 프로세스를 끝까지 진행할 시간이나 관심이 없는 경우, 또는 인터넷에서 자취를 감춘 경우(즉, 연락이 닿지 않거나 이메일에 응답하지 않는 경우)가 있습니다. 저자가 PEP의 방향에 동의하지 않는다는 것은 소유권을 이전할 좋은 이유가 아닙니다. PEP 프로세스의 목표 중 하나는 PEP를 중심으로 합의를 이루려고 노력하는 것입니다. 하지만 합의가 불가능하다면 저자는 언제든지 경쟁 PEP를 제출할 수 있습니다.

PEP의 소유권을 넘겨받고 싶다면 풀 리퀘스트를 통해서도 그렇게 할 수 있습니다. PEP repository를 포크하고, 소유권 정보를 수정한 뒤, 풀 리퀘스트를 제출하십시오. 풀 리퀘스트의 코멘트에서 원저자와 @python/pep-editors를 모두 언급해야 합니다. (원저자의 GitHub 사용자 이름을 모르면 이메일을 사용하십시오.) 원저자가 적절한 시간 안에 응답하지 않으면 PEP 편집자가 일방적으로 결정합니다(그렇다고 그 결정을 되돌릴 수 없는 것도 아닙니다 :).

PEP 편집자의 책임과 워크플로

PEP 편집자는 GitHub의 @python/pep-editors 그룹에 추가되어야 하며, PEP repository를 주시해야 합니다.

PEP repository에 쓰기 권한이 있는 개발자는 보통 PEP 편집자가 맡는 작업을 처리할 수 있다는 점에 유의하십시오. 또는 이러한 개발자라도 GitHub에서 @python/pep-editors를 멘션하여 PEP 편집자에게 도움을 요청할 수 있습니다.

새로 들어오는 각 PEP에 대해 편집자는 다음을 수행합니다:

• PEP가 코어 개발자와 공동 작성되었는지, 코어 개발자를 후원자로 두고 있는지, 또는 운영 위원회(Steering Council)가 이 PEP를 위해 특별히 승인한 후원자를 두고 있는지 확인하십시오.
• PEP를 읽고 준비가 되었는지, 즉 타당하고 완전한지 확인하십시오. 아이디어는 채택될 가능성이 낮아 보이더라도 기술적으로 타당해야 합니다.
• 제목은 내용을 정확하게 설명해야 합니다.
• 파일 이름 확장자가 올바른지(즉, .rst인지) 확인하십시오.
• PEP의 후원자나 공동 저자로 기재된 사람 중 PEP repository에 쓰기 권한이 있는 모든 사람이 .github/CODEOWNERS에 추가되었는지 확인하십시오.
• PEP를 훑어보며 언어(철자, 문법, 문장 구조 등)와 코드 스타일(예제는 PEP 7 및 PEP 8을 준수해야 합니다)에 명백한 결함이 있는지 확인하십시오. 편집자가 문제를 직접 수정할 수도 있지만 반드시 그래야 하는 것은 아닙니다(reStructuredText 문법은 저장소의 CI가 검사합니다).
• 어떤 프로젝트가 PEP로 이점을 얻거나 PEP를 지지하는 것으로 묘사된다면, 그 지지를 분명히 보여 주는 해당 프로젝트의 직접적인 의사 표시가 포함되어 있는지 확인하십시오. 이는 실제로는 추측에 근거한 지지임에도 PEP가 실수로 어떤 프로젝트를 그 PEP의 지지자로 묘사하는 일을 피하기 위한 것입니다.

PEP가 준비되지 않았다면, 편집자는 구체적인 지침과 함께 PEP를 저자에게 돌려보내 수정하도록 합니다. reST 서식이 문제라면, 저자에게 PEP 12를 템플릿으로 사용하여 다시 제출하도록 요청하십시오.

PEP가 저장소에 들어갈 준비가 되면, PEP 편집자는 다음을 수행합니다:

• 저자가 유효한 PEP 번호를 선택했는지 확인하고, 선택하지 않았다면 번호를 할당하십시오(거의 항상 다음으로 사용 가능한 번호이지만, 때로는 666이나 3141 같은 특별한 번호나 농담 번호이기도 합니다).

  100 미만의 번호는 메타 PEP라는 점을 기억하십시오.

• 저자가 PEP의 유형(“Standards Track”, “Informational”, 또는 “Process”)을 올바르게 지정했는지, 그리고 상태를 “Draft”로 표시했는지 확인하십시오.
• 모든 CI 빌드 및 린트 검사가 오류 없이 통과하는지, 그리고 렌더링된 미리 보기 결과에 명백한 문제가 없는지 확인하십시오.
• 새로운(또는 갱신된) PEP를 병합하십시오.
• 저자에게 다음 단계(토론 스레드를 열고 이를 PEP에 반영하기, 공지 게시하기 등)를 알려 주십시오.

기존 PEP에 대한 갱신은 GitHub pull request로 제출해야 합니다.

많은 PEP는 Python 코드베이스에 쓰기 권한이 있는 개발자들이 작성하고 유지 관리합니다. PEP 편집자는 PEP 저장소의 변경 사항을 모니터링하고, 발견한 구조, 문법, 철자 또는 마크업 오류를 수정합니다.

PEP 편집자는 PEP에 대해 판단을 내리지 않습니다. 이들은 단지 행정적이고 편집적인 부분(일반적으로 작업량이 적은 일)을 수행할 뿐입니다.

참고 자료:

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

각주

변경 이력

• 2026-02-02
  • Post-History 헤더를 갱신할 때 변경 사항을 요약할 수 있도록 PEP에 선택적 Change History 섹션을 추가했습니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.