[Active] PEP 1 - PEP Purpose and Guidelines

원문 링크: PEP 1 - PEP Purpose and Guidelines

상태: Active 유형: Process 작성일: 13-Jun-2000

PEP란 무엇인가요?

PEP는 Python Enhancement Proposal의 약자입니다. PEP는 Python 커뮤니티에 정보를 제공하거나, Python 또는 그 프로세스 및 환경을 위한 새로운 기능을 설명하는 디자인 문서입니다. PEP는 기능에 대한 간결한 기술 사양과 해당 기능의 도입 배경을 제공해야 합니다.

PEP는 주요 신기능 제안, 특정 문제에 대한 커뮤니티 의견 수렴, 그리고 Python의 디자인 결정을 문서화하는 주요 메커니즘으로 사용됩니다. PEP 작성자는 커뮤니티 내에서 합의를 도출하고 반대 의견을 문서화할 책임이 있습니다. PEP는 버전 관리되는 텍스트 파일로 유지되므로, 그 개정 이력은 기능 제안의 역사적 기록이 됩니다.

PEP 독자

PEP의 주요 대상 독자는 CPython 레퍼런스 인터프리터의 핵심 개발자와 선출된 Steering Council, 그리고 Python 언어 사양의 다른 구현체 개발자들입니다. 그러나 Python 커뮤니티의 다른 구성원들도 (특히 Informational PEP의 경우) 예상되는 API 규칙을 문서화하고 여러 프로젝트에 걸친 협업이 필요한 복잡한 디자인 조정 문제를 관리하기 위해 이 프로세스를 사용할 수 있습니다.

PEP 유형

PEP는 세 가지 유형으로 나뉩니다.

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

PEP 워크플로우

Python의 Steering Council

“Steering Council” 또는 “Council”은 PEP 13에 설명된 선출된 Steering Council의 현재 구성원을 의미하며, PEP의 수락 또는 거부에 대한 최종 권한을 가집니다.

Python의 Core Developers

“Core Developers”는 PEP 13에 설명된 현재 활동 중인 Python 핵심 팀 구성원을 의미합니다.

Python의 BDFL

이 PEP의 이전 버전에서는 PEP 의사결정자를 “BDFL-Delegate”라고 칭했습니다. 이는 Python의 이전 거버넌스 모델에 대한 역사적 참조로, 모든 디자인 권한이 Python의 창시자인 Guido van Rossum으로부터 파생되었습니다. 현재는 Steering Council이 핵심 개발자들의 선거를 통해 디자인 권한을 얻으며, “BDFL-Delegate” 대신 “PEP-Delegate”가 사용됩니다.

PEP 편집자 (PEP Editors)

PEP 편집자는 PEP 워크플로우의 관리 및 편집 측면 (예: PEP 번호 할당 및 상태 변경)을 담당하는 개인입니다. PEP 편집은 현재 편집자의 초대로 이루어지며, GitHub에서 @python/pep-editors를 멘션하여 연락할 수 있습니다.

Python 아이디어로 시작하기

PEP 프로세스는 Python에 대한 새로운 아이디어로 시작됩니다. 하나의 PEP는 하나의 주요 제안 또는 새로운 아이디어를 포함하는 것이 강력히 권장됩니다. 대부분의 개선 사항과 버그 수정은 PEP를 필요로 하지 않으며 Python 이슈 트래커에 직접 제출할 수 있습니다. PEP 편집자는 너무 광범위하거나 초점이 불분명한 PEP 제안을 거부할 권리가 있습니다.

각 PEP에는 챔피언(champion)이 있어야 합니다. 챔피언은 PEP를 작성하고, 적절한 포럼에서 논의를 이끌며, 아이디어에 대한 커뮤니티 합의를 구축하려고 노력하는 사람입니다. PEP 챔피언(저자)은 먼저 해당 아이디어가 PEP로 작성 가능한지 확인해야 합니다. 이를 위해 Python Discourse의 Ideas 카테고리에 게시하는 것이 일반적으로 가장 좋은 방법입니다.

PEP를 작성하기 전에 아이디어를 공개적으로 검토하는 것은 잠재적 저자의 시간을 절약하기 위한 것입니다. 아이디어가 수용될 가능성이 있는지 Python 커뮤니티에 물어본 후, 초안 PEP는 위에서 언급된 적절한 장소에 제출되어야 합니다.

PEP 제출

초기 논의 후 워크플로우는 PEP 공동 저자 중 핵심 개발자가 있는지 여부에 따라 달라집니다. 핵심 개발자가 공동 저자인 경우, 그들이 아래에 설명된 프로세스를 따릅니다. 그렇지 않은 경우, PEP 저자는 PEP 스폰서(sponsor)를 찾아야 합니다.

스폰서는 PEP 저자가 PEP 프로세스의 물류를 통과할 수 있도록 지침을 제공하는 역할을 합니다. 스폰서 또는 핵심 개발자 공동 저자가 PEP 제출 준비가 되었다고 판단하면, 제안은 GitHub Pull Request를 통해 초안 PEP로 제출되어야 합니다.

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

  1. PEP 저자는 PEP 저장소를 포크(fork)하고 새 PEP를 포함하는 pep-NNNN.rst 파일을 생성합니다.
  2. PEP 헤더 필드에 PEP 번호와 유형(“Standards Track”, “Informational”, “Process”), 상태(“Draft”)를 입력합니다.
  3. .github/CODEOWNERS 파일을 업데이트하여 공동 저자 또는 스폰서가 새 파일에 대한 쓰기 권한을 가지도록 합니다.
  4. GitHub 포크에 푸시하고 Pull Request를 제출합니다.
  5. PEP 편집자는 구조, 형식 및 기타 오류에 대해 PR을 검토합니다.
  6. 승인되면 PEP 번호가 할당됩니다.
  7. 검토 프로세스가 완료되고 PEP 편집자가 승인하면 Pull Request가 main 브랜치에 squash commit됩니다.

PEP 편집자는 노력의 중복, 기술적으로 불건전함, 적절한 동기 부여 부족 또는 이전 버전과의 호환성 문제 미해결, Python 철학에 부합하지 않음 등의 이유로 PEP 게시를 거부할 수 있습니다. Steering Council은 승인 단계에서 상담될 수 있으며, 초안의 PEP-able 여부에 대한 최종 중재자입니다.

Standards Track PEP는 디자인 문서와 참조 구현이라는 두 부분으로 구성됩니다. 일반적으로 최소한 프로토타입 구현이 PEP와 함께 개발될 것을 권장합니다.

PEP 논의

PEP 번호가 할당되고 초안 PEP가 PEP 저장소에 커밋되면, PEP에 대한 논의 스레드가 생성되어 내용 논의 및 검토를 위한 중앙 집중식 장소를 제공해야 합니다. PEP의 Discussions-To 헤더는 해당 스레드에 연결되어야 합니다.

PEP 저자(또는 스폰서)는 PEP의 주제에 적합하고, 모든 이해 관계자가 참여할 수 있도록 웹에서 공개적으로 이용 가능하며, Python 커뮤니티 행동 강령을 준수하는 한, 어떤 합리적인 논의 장소든 선택할 수 있습니다. Python Discourse의 PEPs 카테고리가 대부분의 새로운 PEP에 선호되는 선택입니다.

PEP가 상당한 재작성 또는 기타 주요, 실질적인 변경을 거치는 경우, 추가 피드백을 얻기 위해 일반적으로 선택된 장소에 새로운 스레드가 생성되어야 합니다.

PEP 검토 및 해결 (PEP Review & Resolution)

저자가 PEP를 완료하면, PEP 편집자에게 스타일 및 일관성 검토를 요청할 수 있습니다. 그러나 PEP의 내용 검토 및 수락은 궁극적으로 Steering Council의 책임입니다. Steering Council은 PEP 저자(및 스폰서)가 최종 검토 및 해결 준비가 되었다고 판단하면 Steering Council 이슈를 열어 공식적으로 시작합니다.

PEP 승인에 대한 최종 권한은 Steering Council에 있습니다. 그러나 새로운 PEP가 제출될 때마다, 해당 PEP에 대한 최종 결정을 내릴 만큼 충분히 경험이 있다고 생각하는 핵심 개발자는 Steering Council에 의사를 통지하여 PEP-Delegate로 봉사하겠다고 제안할 수 있습니다. Steering Council이 제안을 승인하면, PEP-Delegate는 해당 PEP를 승인하거나 거부할 권한을 가집니다.

PEP가 수락되려면 특정 최소 기준을 충족해야 합니다. 제안된 개선 사항에 대한 명확하고 완전한 설명이어야 합니다. 개선 사항은 순 개선(net improvement)을 나타내야 합니다. 제안된 구현은 견고해야 하며 인터프리터를 과도하게 복잡하게 만들지 않아야 합니다. 마지막으로, 제안된 개선 사항은 “pythonic”해야 Steering Council에 의해 수락될 수 있습니다.

PEP가 수락되면, 참조 구현이 완료되어야 합니다. 참조 구현이 완료되어 주 소스 코드 저장소에 통합되면 상태는 “Final”로 변경됩니다.

언어 기능 또는 표준 라이브러리 API에 대한 장기적인 안정성에 전념하기 전에 추가적인 디자인 및 인터페이스 피드백을 수집하기 위해, PEP는 “Provisional”로 표시될 수도 있습니다. 이는 “잠정적으로 수락됨(Provisionally Accepted)”을 의미하며, 제안이 참조 구현에 포함되는 것이 수락되었지만, 전체 디자인이 “Final”로 간주되기 전에 추가 사용자 피드백이 필요하다는 것을 나타냅니다.

PEP는 “Deferred” 상태가 할당될 수도 있습니다. PEP 저자 또는 편집자는 PEP에 진전이 없을 때 이 상태를 할당할 수 있습니다.

PEP는 “Rejected”될 수도 있습니다. 모든 것이 고려된 후에도 좋은 아이디어가 아니었다면, 이 사실을 기록하는 것이 중요합니다. “Withdrawn” 상태도 유사하며, PEP 저자 자신이 PEP가 실제로 나쁜 아이디어라고 결정했거나, 경쟁하는 제안이 더 나은 대안임을 수락했음을 의미합니다.

PEP의 가능한 상태 경로는 다음과 같습니다. (PEP 프로세스 흐름도 참조). “Accepted” PEP는 기술적으로 수락 후에도 “Rejected” 또는 “Withdrawn”으로 이동할 수 있습니다.

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

PEP 유지 관리 (PEP Maintenance)

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

Active (Informational 및 Process) PEP는 개발 관행 및 기타 세부 사항의 변경을 반영하기 위해 시간이 지남에 따라 업데이트될 수 있습니다.

성공적인 PEP에 포함되어야 할 내용

각 PEP는 다음 부분/섹션을 포함해야 합니다.

  • Preamble (전문): PEP 번호, 짧은 설명 제목, 저자 이름 등 PEP에 대한 메타데이터를 포함하는 RFC 2822 스타일의 헤더입니다.
  • Abstract (요약): 다루어지는 기술적 문제에 대한 짧은(~200단어) 설명입니다.
  • Motivation (동기): Python 언어, 라이브러리 또는 생태계를 변경하려는 PEP에 매우 중요합니다. 기존 언어 사양이 PEP가 해결하는 문제를 다루기에 부적절한 이유를 명확하게 설명해야 합니다.
  • Rationale (근거): 특정 디자인 결정이 내려진 이유를 설명하여 사양을 상세화합니다. 고려되었던 대체 디자인과 관련 작업(예: 다른 언어에서 해당 기능이 어떻게 지원되는지)을 설명해야 합니다.
  • Specification (사양): 새로운 언어 기능의 구문과 의미를 설명해야 합니다. 최소한 현재 주요 Python 플랫폼(CPython, Jython, IronPython, PyPy)에 대한 경쟁적이고 상호 운용 가능한 구현을 허용할 만큼 충분히 상세해야 합니다.
  • Backwards Compatibility (이전 버전 호환성): 이전 버전과의 비호환성을 도입하는 모든 PEP는 이러한 비호환성과 그 심각도를 설명하는 섹션을 포함해야 합니다. 저자는 이러한 비호환성을 어떻게 처리할지 설명해야 합니다.
  • Security Implications (보안 영향): PEP와 관련하여 보안 문제가 있다면, PEP 검토자들이 이를 인지할 수 있도록 명시적으로 작성해야 합니다.
  • How to Teach This (교육 방법): 새로운 기능을 추가하거나 언어 동작을 변경하는 PEP의 경우, 신규 및 숙련된 사용자에게 PEP를 작업에 적용하는 방법을 가르치는 방법에 대한 섹션을 포함하는 것이 도움이 됩니다.
  • Reference Implementation (참조 구현): 어떤 PEP도 “Final” 상태를 부여받기 전에 참조 구현이 완료되어야 하지만, PEP가 수락되기 전에 완료될 필요는 없습니다.
  • Rejected Ideas (거부된 아이디어): PEP 논의 과정에서 제안되었지만 수락되지 않은 다양한 아이디어는 거부 이유와 함께 기록되어야 합니다.
  • Open Issues (미해결 문제): PEP가 초안 단계에 있는 동안, 추가 논의가 필요한 아이디어는 기록되어야 합니다.
  • Acknowledgements (감사): PEP 개발, 논의 또는 초안 작성에 도움을 준 사람들에게 감사하고 인정하는 데 유용합니다.
  • Footnotes (각주): PEP에 인용된 각주의 모음입니다.
  • Copyright/license (저작권/라이선스): 각 새 PEP는 퍼블릭 도메인 및 CC0-1.0-Universal 이중 라이선스 하에 놓여야 합니다.

PEP 형식 및 템플릿

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

PEP 헤더 전문 (Preamble)

각 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의 모든 저자/소유자의 이름과 선택적으로 이메일 주소를 나열합니다.
  • Sponsor: PEP를 후원하는 개발자(코어 개발자 또는 Steering Council이 특별히 승인한 개발자)를 기록합니다.
  • PEP-Delegate: Steering Council이 PEP의 승인 또는 거부에 대한 최종 결정을 내리도록 임명한 개인을 기록합니다.
  • Discussions-To: PEP에 대한 현재 표준 논의 스레드의 URL을 제공합니다.
  • Type: PEP의 유형을 지정합니다 (Standards Track, Informational, Process).
  • Topic (선택 사항): PEP가 속하는 특별 주제를 나열합니다.
  • Created: PEP 번호가 할당된 날짜를 기록합니다.
  • Python-Version (Standards Track PEP에 해당): 기능이 출시될 Python 버전을 나타냅니다.
  • Requires (선택 사항): 이 PEP가 의존하는 PEP 번호를 나타냅니다.
  • Superseded-By (선택 사항): PEP가 나중에 다른 문서에 의해 구식화되었음을 나타냅니다.
  • Resolution (Standards Track PEP에 필수): PEP에 대한 결정(승인 또는 거부)이 내려진 이메일 메시지 또는 기타 웹 리소스로 연결되는 URL을 포함합니다.

보조 파일 (Auxiliary Files)

PEP는 다이어그램과 같은 보조 파일을 포함할 수 있습니다. 이러한 파일은 pep-XXXX-Y.ext 형식으로 명명되어야 합니다. 또는 모든 지원 파일은 pep-XXXX라는 하위 디렉토리에 배치될 수 있습니다.

기존 PEP 변경 (Changing Existing PEPs)

초안 PEP는 저자의 재량에 따라 자유롭게 논의 및 수정 제안이 가능하며, Steering Council 또는 PEP-Delegate에게 검토 및 해결을 위해 제출될 때까지 변경될 수 있습니다. 실질적인 내용 변경은 일반적으로 PEP의 Discussions-To 헤더에 나열된 논의 스레드에서 먼저 제안되어야 합니다.

PEP 소유권 이전 (Transferring PEP Ownership)

PEP의 소유권을 새로운 챔피언에게 이전해야 할 때가 있습니다. 이는 주로 원래 저자가 더 이상 업데이트하거나 PEP 프로세스를 따를 시간이나 관심이 없거나 연락이 닿지 않을 때 발생합니다. 소유권을 이전하려는 경우, Pull Request를 통해 진행할 수 있습니다.

PEP 편집자의 책임 및 워크플로우 (PEP Editor Responsibilities & Workflow)

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

새로운 PEP가 제출되면 편집자는 다음을 수행합니다.

  1. PEP가 핵심 개발자에 의해 공동 작성되었거나, 핵심 개발자를 스폰서로 두었거나, Steering Council이 특별히 승인한 스폰서를 가지고 있는지 확인합니다.
  2. PEP를 읽고 준비되었는지 확인합니다: 타당하고 완전하며, 기술적으로 의미가 있어야 합니다.
  3. .github/CODEOWNERS에 스폰서나 공동 저자가 추가되었는지 확인합니다.
  4. 언어 (철자, 문법, 문장 구조 등) 및 코드 스타일 (PEP 7 & PEP 8 준수)의 명백한 결함을 검토합니다.
  5. PEP가 프로젝트에 도움이 되거나 지원한다고 묘사되는 경우, 해당 프로젝트의 직접적인 표시가 포함되어 있는지 확인합니다.

PEP가 준비되지 않았다면, 편집자는 구체적인 지침과 함께 저자에게 수정을 위해 다시 보냅니다.

PEP가 저장소에 추가될 준비가 되면 PEP 편집자는 다음을 수행합니다.

  1. 저자가 유효한 PEP 번호를 선택했는지 확인하거나 할당합니다.
  2. 저자가 PEP 유형(“Standards Track”, “Informational”, “Process”)을 올바르게 레이블링하고 상태를 “Draft”로 표시했는지 확인합니다.
  3. 모든 CI 빌드 및 린트 검사가 오류 없이 통과하고 렌더링된 미리 보기 출력에 명백한 문제가 없는지 확인합니다.
  4. 새로운 (또는 업데이트된) PEP를 병합합니다.
  5. 저자에게 다음 단계 (논의 스레드 열기, PEP 업데이트, 공지 게시 등)를 알립니다.

PEP 편집자는 PEP에 대한 판단을 내리지 않고, 단지 관리 및 편집 부분을 수행합니다.

이 문서는 퍼블릭 도메인 또는 CC0-1.0-Universal 라이선스 중 더 관대한 조건에 따라 배포됩니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments