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 워크플로
  • 파이썬의 운영 위원회(Steering Council)
  • 파이썬의 핵심 개발자
  • 파이썬의 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는 파이썬 커뮤니티에 정보를 제공하거나 파이썬 또는 그 프로세스나 환경에 대한 새로운 기능을 설명하는 설계 문서입니다. PEP는 해당 기능에 대한 간결한 기술 명세와 근거를 제공해야 합니다.

PEP는 주요 신규 기능을 제안하고, 어떤 사안에 대한 커뮤니티의 의견을 수집하며, 파이썬에 반영된 설계 결정을 문서화하는 주된 메커니즘이 되는 것을 의도합니다. PEP 작성자는 커뮤니티 내에서 합의를 형성하고 반대 의견을 문서화할 책임이 있습니다.

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

PEP 대상 독자

PEP의 전형적인 주요 대상 독자는 CPython 참조 인터프리터의 핵심 개발자와 그들이 선출한 운영위원회(Steering Council), 그리고 파이썬 언어 명세의 다른 구현체 개발자들입니다.

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

PEP 유형

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

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

PEP 워크플로

파이썬의 운영 위원회(Steering Council)

이 PEP에는 “운영 위원회(Steering Council)” 또는 “위원회(Council)”에 대한 언급이 여러 차례 나옵니다. 이는 PEP의 승인 또는 거부 여부에 대한 최종 권한을 갖는 역할로서, PEP 13에 설명된 선출된 운영 위원회의 현재 구성원을 가리킵니다.

파이썬의 핵심 개발자

이 PEP에는 “핵심 개발자(core developers)”에 대한 언급이 여러 차례 나옵니다. 이는 PEP 13에 설명된 현재 활동 중인 파이썬 핵심 팀 구성원을 가리킵니다.

파이썬의 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로 만들 만한지 확인해야 합니다. 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” 팀의 구성원과 타이핑 위원회(PEP 729)의 구성원은 스폰서로 사전 승인되어 있습니다. 스폰서의 역할은 PEP 저자가 PEP 절차의 실무를 해쳐 나가도록 안내를 제공하는 것입니다(다소 멘토와 같은 역할을 합니다). 스폰서가 되었다고 해서 그 사람이 나중에 공동 저자나 PEP 대리인이 되는 것이 금지되는 것은 아닙니다 (단, 둘 다 될 수는 없습니다). 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를 채택하는 것과 같지 않다는 점에 유의하십시오!), 편집자는 여러분의 풀 리퀘스트를 main에 스쿼시 커밋합니다.

PEP 편집자는 부당하게 PEP의 발행을 거부하지 않습니다. PEP 상태를 거부하는 이유로는 노력의 중복, 기술적으로 부실함, 적절한 동기 부여나 하위 호환성 처리의 부재, 또는 Python 철학에 부합하지 않음 등이 있습니다. 운영 위원회는 승인 단계에서 자문을 받을 수 있으며, 초안의 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에 대한 논의 스레드를 생성해야 하며, Discussions-To 헤더가 그곳으로 연결되도록 PEP를 업데이트해야 합니다.

PEP 저자(또는 해당되는 경우 스폰서)는 다음 기준이 충족되는 한 논의를 위한 적절한 장소를 자유롭게 선택할 수 있습니다.

• 포럼은 해당 PEP의 주제에 적합해야 합니다.
• 관심 있는 모든 당사자가 참여할 수 있도록 스레드는 웹에서 공개적으로 이용 가능합니다.
• 논의는 Python Community Code of Conduct를 따릅니다.
• 현재 논의 스레드로의 직접 링크는 PEP의 Discussions-To 헤더 아래에 제공됩니다.

Python Discourse의 PEPs category는 대부분의 새로운 PEP에 선호되는 선택지이며, 반면 역사적으로는 Python-Dev 메일링 리스트가 흔히 사용되었습니다. 일부 전문화된 주제는 타이핑 PEP와 패키징 PEP를 위한 Python Discourse의 Typing category 및 Packaging category와 같이 특정한 논의 장소를 가지고 있습니다. PEP 작성자가 최선의 장소를 확신하지 못하는 경우, PEP 스폰서와 PEP 편집자가 이에 따라 조언할 수 있습니다.

PEP가 상당한 재작성이나 제안된 명세에 대한 그 밖의 주요하고 실질적인 변경을 겪는 경우, 일반적으로 추가 피드백을 구하기 위해 선택된 장소에 새로운 스레드가 생성되어야 합니다. 이런 일이 발생하면, Discussions-To 링크가 갱신되어야 하며, 이 새로운 스레드를 가리키는 새로운 Post-History 항목이 추가되어야 합니다.

그것이 논의 장소로 선택되지 않은 경우, 초안 PEP가 저장소에 커밋될 때 그리고 새로운 스레드를 유발할 만큼 충분히 큰 변경이 이루어진 경우, 최소한 렌더링된 PEP에 대한 링크와 Discussions-To 스레드를 포함하는 간단한 공지 게시물이 PEPs category에 작성되어야 합니다.

PEP 작성자는 검토를 위해 PEP를 제출하기 전에 커뮤니티 피드백을 수집할 책임이 있습니다. 하지만 장황하고 결론 없는 논의를 피하기 위해, 초기 설계 단계에서 비공개적이거나 더 좁게 조정된 피드백을 구하는 것, PEP 주제에 전문성을 가진 다른 커뮤니티 구성원과 협업하는 것, 그리고 (해당하는 경우) PEP의 주제에 적절히 특화된 논의를 선택하는 것과 같은 전략을 고려해야 합니다. PEP 작성자는 이 부분에서 자신의 재량을 사용해야 합니다.

PEP에 번호가 할당되고 PEP 저장소에 커밋되면, 실질적인 쟁점은 비공개 채널, GitHub 풀 리퀘스트 리뷰 또는 무관한 장소가 아니라 일반적으로 정규 공개 스레드에서 논의되어야 합니다. 이는 모든 사람이 따라가고 기여할 수 있도록 보장하고, 논의가 분산되는 것을 방지하며, PEP 검토 과정의 일부로서 완전히 고려되도록 보장합니다. 이 지정된 스레드에 대한 의견, 지지, 우려 및 그 밖의 피드백은 운영 위원회 또는 PEP 위임자가 PEP를 검토할 때 고려할 사항의 핵심적인 부분입니다.

PEP 검토 및 결정

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

특정 경우(예: 변경 사항이 명백히 유익하고 승인될 준비가 되어 있지만 PEP가 아직 공식적으로 검토를 위해 제출되지 않은 경우)에 절차를 신속히 진행하기 위해, Steering Council은 먼저 PEP 저자(들)에게 통지하고 수정할 기회를 준 뒤 PEP 검토를 직접 시작할 수도 있습니다.

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

“PEP-Delegate”라는 용어는 Steering Council 거버넌스 모델에서 PEP의 지정된 의사 결정자를 가리키는 데 사용되며, 이 사람은 PEP 헤더의 “PEP-Delegate” 필드에 기록됩니다. “BDFL-Delegate”라는 용어는 PEP-Delegate의 더 이상 쓰이지 않는 별칭으로, Python이 BDFL에 의해 이끌리던 시절의 유산입니다. “BDFL-Delegate”에 대한 모든 오래된 언급은 “PEP-Delegate”와 동등한 것으로 취급되어야 합니다.

PEP-Delegate로 스스로를 지명하고자 하는 사람은 관련 저자들과 (있는 경우) PEP의 후원자에게 통지하고, 새 이슈를 통해 Steering Council에 요청을 제출해야 합니다. 이러한 책임을 맡는 사람들은 언제든지 Steering Council에 추가적인 지침을 자유롭게 구할 수 있으며, 다른 코어 개발자들의 조언과 관점도 고려할 것으로 기대됩니다.

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

자원자가 나서지 않는 경우, 운영 위원회는 해당 PEP의 PEP-위임자 역할을 맡으려는 후보자를 찾기 위해 관련 전문성을 갖춘 핵심 개발자(및 필요에 따라 다른 파이썬 커뮤니티 구성원)에게 접촉합니다. 적합한 후보자를 찾을 수 없는 경우, 해당 PEP는 적합한 후보자가 나타날 때까지 보류(Deferred) 상태로 표시됩니다.

이전에 임명된 PEP-위임자는 스스로 물러나기로 선택하거나 위원회의 요청으로 물러날 수 있으며, 이 경우 새로운 PEP-위임자는 신규 PEP의 경우와 동일한 방식으로 임명됩니다(적합한 후임자를 찾을 수 없는 경우 해당 PEP의 보류 처리를 포함합니다). PEP-위임자가 물러나도록 요청받는 경우, 이는 해당 PEP에 대한 이전의 승인 또는 거부를 무효화하며, 해당 PEP는 초안(Draft) 상태로 되돌아갑니다.

이러한 상시 위임이 마련되는 경우, 운영 위원회는 후속 위원회, 핵심 개발자, 그리고 더 넓은 파이썬 커뮤니티가 현재 존재하는 위임 관계, 그것이 마련된 이유, 그리고 더 이상 필요하지 않게 될 수 있는 상황을 이해할 수 있도록 충분한 공개 기록을 유지합니다.

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

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

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

언어 기능이나 표준 라이브러리 API의 장기적 안정성을 확정 짓기 전에 추가적인 설계 및 인터페이스 피드백을 수집할 수 있도록, PEP는 “Provisional”(잠정)로도 표시될 수 있습니다. 이는 “Provisionally Accepted”(잠정 승인)의 줄임말로, 제안이 참조 구현에 포함되도록 승인되었지만, 전체 설계가 “Final”(최종)로 간주되기 전에 추가적인 사용자 피드백이 필요함을 나타냅니다. 일반적으로 승인된 PEP와 달리, 잠정 승인된 PEP는 관련 변경 사항이 파이썬 릴리스에 포함된 이후에도 여전히 거부되거나 철회될 수 있습니다.

가능한 경우, “Provisional”(잠정) 상태에 의존할 필요를 피하도록 제안의 범위를 줄이는 것이 바람직하다고 여겨집니다(예: 일부 기능을 이후의 PEP로 미루는 방식으로). 이 상태는 더 넓은 파이썬 생태계에서 버전 호환성 문제를 야기할 수 있기 때문입니다. PEP 411은 잠정 상태의 잠재적 사용 사례에 대한 추가 세부 정보를 제공합니다.

“Deferred”(보류) 상태도 PEP에 지정될 수 있습니다. PEP 작성자나 편집자는 PEP에 진행 상황이 없을 때 이 상태를 지정할 수 있습니다. PEP가 보류되면, PEP 편집자는 이를 초안 상태로 다시 지정할 수 있습니다.

PEP는 또한 “Rejected”(거부)될 수 있습니다. 결국 모든 것이 논의된 후에도 좋은 아이디어가 아니었을 수 있습니다. 그렇더라도 이 사실을 기록해 두는 것은 여전히 중요합니다. “Withdrawn”(철회) 상태도 이와 유사합니다. 이는 PEP 작성자 자신이 해당 PEP가 사실 좋지 않은 아이디어라고 판단했거나, 경쟁하는 제안이 더 나은 대안이라는 것을 받아들였음을 의미합니다.

PEP가 승인, 거부 또는 철회되면, 그에 맞게 PEP를 갱신해야 합니다. Status 필드를 갱신하는 것 외에도, 최소한 해당 PEP에 대한 결정을 내린 게시물로 직접 연결되는 링크와 함께 Resolution 헤더를 추가해야 합니다.

PEP는 다른 PEP에 의해 대체되어 원래의 PEP가 폐기될 수도 있습니다. 이는 정보 제공용(Informational) PEP를 위한 것으로, API의 버전 2가 버전 1을 대체할 수 있는 경우입니다.

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

그림에는 나와 있지 않지만, “Accepted” 상태의 PEP는 채택 이후라도 기술적으로 “Rejected”나 “Withdrawn”으로 이동할 수 있습니다. 이는 구현 과정에서 PEP 승인 이전에는 발견되지 못했던 설계상의 근본적인 결함이 드러나는 경우에만 발생합니다. Provisional PEP와 달리, 이러한 전환은 승인된 제안이 아직 파이썬 릴리스에 포함되지 않은 경우에만 허용됩니다. 이미 릴리스된 변경 사항은 대신 일반적인 폐기 절차(폐기의 근거를 제시하는 새 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 상태이거나 심지어 Withdrawn 상태인 PEP가 대규모 업데이트를 거쳐 부활되는 경우도 있지만, 대개는 새로운 PEP를 제안하는 편이 더 낫습니다.

성공적인 PEP에는 무엇이 포함되어야 하는가?

각 PEP는 다음과 같은 부분/섹션을 가져야 합니다.

1. 서문 – PEP에 관한 메타데이터를 담은 RFC 2822 형식의 헤더로, PEP 번호, (최대 44자로 제한된) 짧은 설명적 제목, 각 저자의 이름, 그리고 선택적으로 연락처 정보 등을 포함합니다.
2. Abstract – 다루고 있는 기술적 문제에 대한 짧은(~200단어) 설명입니다.
3. Motivation – 동기는 Python 언어, 라이브러리, 또는 생태계를 변경하고자 하는 PEP에 있어 결정적으로 중요합니다. 기존 언어 명세가 해당 PEP가 해결하려는 문제를 다루기에 왜 부적절한지를 명확히 설명해야 합니다. 여기에는 Python 생태계 내 주요 프로젝트들로부터 해당 PEP에 대한 지지를 문서화하여 수집하는 것이 포함될 수 있습니다. 충분한 동기가 제시되지 않은 PEP 제출은 거부될 수 있습니다.
4. Specification – 기술 명세는 새로운 언어 기능의 구문과 의미를 기술해야 합니다. 명세는 적어도 현재의 주요 Python 플랫폼(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. 참조 구현 – 참조 구현은 어떤 PEP든 “Final” 상태가 부여되기 전에 완료되어야 하지만, PEP가 수락되기 전에 완료될 필요는 없습니다. 코드를 작성하기 전에 명세와 근거에 대한 합의에 도달하는 접근 방식에도 장점이 있지만, API 세부 사항에 관한 많은 논의를 해결하는 데에는 “대략적인 합의와 실행되는 코드”라는 원칙이 여전히 유용합니다.

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

10. 거부된 아이디어 – PEP에 대한 논의가 진행되는 동안, 채택되지 않는 다양한 아이디어가 제안될 것입니다. 그러한 거부된 아이디어는 왜 거부되었는지에 대한 근거와 함께 기록되어야 합니다. 이는 PEP 최종본 이면의 사고 과정을 기록하는 데 도움이 될 뿐만 아니라, 이후 논의에서 사람들이 동일한 거부된 아이디어를 다시 꺼내는 것을 방지해 줍니다.

    어떤 의미에서 이 절은 특정 아이디어가 최종적으로 채택되지 않은 이유에 구체적으로 초점을 맞춘, 근거 절에서 파생된 절로 볼 수 있습니다.

11. 미해결 사안 – PEP가 초안 상태인 동안, 추가 논의가 필요한 아이디어가 생길 수 있습니다. 그러한 아이디어는 사람들이 그것이 고려되고 있다는 것은 알지만 구체적인 해결책은 아직 없다는 것을 알 수 있도록 기록되어야 합니다. 이는 PEP가 검토될 준비를 갖추는 데 필요한 모든 사안이 완비되었는지 확인하는 데 도움이 되며, 사람들이 이전 논의를 중복하는 일을 줄여 줍니다.
12. 감사의 말 – PEP를 개발하거나 논의하거나 초안을 작성하는 데 도움을 준 사람들, 또는 그 밖의 어떤 목적으로든 도움을 준 사람들에게 감사와 사의를 표하는 데 유용합니다. 이 절은 공동 저자가 아닌 작업 기여자를 인정하는 데 사용될 수 있습니다.
13. 각주 – PEP에서 인용된 각주들의 모음이며, 본문에 포함되지 않은 하이퍼링크 대상을 나열하는 곳입니다.

변경 이력 – PEP가 겪은 주요 변경 사항의 요약으로, 다음을 기준으로 합니다.

논의와 피드백. 이를 PEP의 “변경 이력(changelog)” 또는 “릴리스 노트”라고 생각하십시오. 일반적으로 주요 변경 사항에 대해 Post-History 헤더를 업데이트할 때마다, 동일한 DD-MMM-YYYY 형식을 사용하여 최신순(즉, 역순 시간순)으로 새 글머리 항목을 추가하고, 변경 사항을 요약하는 하위 글머리 항목을 함께 붙이십시오. 이를 Post-History 링크와 동일한 링크로 연결하는 것을 고려할 수 있습니다. 이는 필수 사항이 아니므로 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을 기록하는 데 사용되는데, 전자는 링크된 텍스트로, 후자는 링크 대상으로 사용됩니다. 두 날짜 세트 모두 dd-mmm-yyyy 형식(예: 14-Aug-2001)이어야 합니다.

표준 트랙 PEP는 일반적으로 해당 기능이 릴리스될 파이썬 버전을 나타내는 Python-Version 헤더를 가집니다. Python-Version 헤더가 없는 표준 트랙 PEP는 처음에는 외부 라이브러리와 도구를 통해 지원되다가, 이후 표준 라이브러리에 대한 지원을 추가하는 후속 PEP로 보완될 가능성이 있는 상호운용성 표준을 나타냅니다. 정보 제공용 PEP와 절차 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 변경하기

초안 상태의 PEP는 운영위원회(Steering Council)나 PEP 위임자(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의 소유권을 새로운 옹호자(champion)에게 이전해야 할 필요가 가끔 생깁니다. 일반적으로는 이전된 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 repository에 대한 쓰기 권한이 있는, PEP의 후원자 또는 공동 저자로 등재된 모든 사람이 .github/CODEOWNERS에 추가되었는지 확인하십시오.
• PEP를 훑어보며 언어(맞춤법, 문법, 문장 구조 등)와 코드 스타일(예제는 PEP 7과 PEP 8을 준수해야 함)의 명백한 결함을 확인하십시오. 편집자는 직접 문제를 수정할 수 있지만, 반드시 그렇게 해야 하는 것은 아닙니다(reStructuredText 문법은 저장소의 CI에서 검사됩니다).
• 어떤 프로젝트가 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.