📬 PEP 0 : PEPs 목차
📬 PEP 1 : PEP 목적 및 가이드라인
📬 PEP 8 : Python 코드에 대한 스타일 가이드라인
→ PEP 에 대한 전반적인 소개입니다.
<목차>
- PEP Introduction
- PEP Types (3가지)
- Meta-PEPs (PEPs about PEPs or Processes) 목록
- PEP8 Introduction
- A Foolish Consistency is the Hobgoblin of Little Minds
▶︎ PEP Introduction
- PEP 는 Python Enhancement Proposal 의 약자이다.
- PEP 는 Python 커뮤니티에 정보를 제공하거나 Python 또는 Python 프로세스, 환경에 대한 새로운 기능을 설명하는 디자인 문서이다.
- PEP 는 기능에 대한 간결한 기술 사양과 기능에 대한 근거를 제공해야 한다.
- 우리는 PEP 가 주요 새 기능을 제안하고, 문제에 대한 커뮤니티 의견을 수집하고, Python 에 적용된 설계 결정을 문서화하기 위한 기본 메커니즘이 되기를 바란다.
- PEP 작성자는 커뮤니티 내에서 합의를 구축하고 반대 의견을 문서화할 책임이 있다.
- PEP 는 버전이 지정된 레포지토리에서 텍스트 파일로 유지 관리되기 때문에 개정 기록은 기능 제안의 역사적 기록이다.
▶︎ PEP Types (3가지)
- 표준 트랙 PEP (Standards Track)
- Python 의 새로운 기능 또는 구현을 설명한다.
- 후속 PEP 가 미래 버전에서 표준 라이브러리 지원을 추가하기 전에 현재 Python 버전에 대한 표준 라이브러리 외부에서 지원될 상호 운용성 표준을 설명할 수도 있다.
- 정보용 PEP (Informational)
- Python 디자인 문제를 설명하거나 Python 커뮤니티에 일반 지침 또는 정보를 제공하지만 새로운 기능을 제안하지는 않는다.
- 정보용 PEP 가 반드시 Python 커뮤니티 합의 또는 권장 사항을 나타내는 것은 아니므로 사용자와 구현자는 자유롭게 정보용 PEP 를 무시하거나 조언을 따를 수 있다.
- 프로세스 PEP (Process)
- Python 을 둘러싼 프로세스를 설명하거나 프로세스의 변경 (또는 이벤트)를 제안한다.
- 프로세스 PEP 는 표준 트랙 PEP 와 비슷하지만 Python 언어 자체 이외의 영역에 적용된다.
- 그들은 구현을 제안할 수 있지만 Python 의 코드베이스에는 제안하지 않는다.
- 종종 커뮤니티 합의가 필요하다.
- 정보용 PEP 와 달리 권장 사항 이상이며 사용자는 일반적으로 이를 무시할 수 없다.
- [ex] 절차, 지침, 의사 결정 프로세스의 변경 사항, Python 개발에 사용되는 도구 또는 환경의 변경 사항 포함. 모든 메타 PEP 도 프로세스 PEP 로 간주한다.
Meta-PEPs (PEPs about PEPs or Processes)
| PEP | PEP Title | PEP Author(s) |
| 1 | PEP 목적과 가이드 라인 | Warsaw, Hylton, Goodger, Coghlan |
| 4 | 사용되지 않는 표준 모듈 | Cannon, von Löwis |
| 5 | Language Evolution 가이드라인 | Prescod |
| 6 | Bug Fix Releases | Aahz, Baxter |
| 7 | C 코드에 대한 스타일 가이드라인 | GvR, Warsaw |
| 8 | Python 코드에 대한 스타일 가이드라인 | GvR, Warsaw, Coghlan |
| 10 | Python-dev 투표 지침 | Warsaw |
| 11 | 더 이상 지원되지 않는 플랫폼 | von Löwis, Cannon |
| 12 | ReStructuredText PEP 샘플 템플릿 | Goodger, Warsaw, Cannon |
| 387 | 이전 버전과의 호환성 정책 | Peterson |
| 609 | PyPA Governance | Ingram, Gedam, Harihareswara |
| 676 | PEP Infra 프로세스 | Turner |
▶︎ PEP8 Introduction
- PEP 8 은 파이썬 코드의 작성규칙 (code convention) 에 대해 설명하는 문서이다.
- 이 스타일 가이드는 추가 규칙이 식별되고 언어 자체의 변경으로 인해 과거 규칙이 더 이상 사용되지 않게 됨에 따라 시간이 지남에 따라 발전한다.
- 많은 프로젝트에는 고유한 코딩 스타일 지침이 있다. 충돌이 있는 경우 해당 프로젝트에 대해 해당 프로젝트별 가이드가 우선 적용된다.
- PEP 8 은 권장사항이지 절대적인 법칙은 아니다.
▶︎ A Foolish Consistency is the Hobgoblin of Little Minds
- Guido 의 주요 통찰력 중 하나는 코드가 작성된 것보다 훨씬 더 자주 읽혀진다는 것이다.
- 여기에 제공된 지침은 코드의 가독성을 개선하고 광범위한 Python 코드에서 일관성을 유지하기 위한 것이다.
- PEP 20 에서 말했듯이 “가독성이 중요하다”.
- 일관성 중요도 (높음 → 낮음)
- 하나의 모듈 또는 기능 내에서의 일관성
- 프로젝트 내에서의 일관성
- PEP 8 스타일 가이드와의 일관성
- 특정 지침을 무시해야하는 다른 좋은 이유
- 지침을 적용하면 이 PEP 를 따르는 코드를 읽는데 익숙한 사람이라도 코드 가독성이 떨어질 때.
- (아마도 역사적인 이유로 인해) 코드를 깨뜨리기도 하는 주변 코드와의 일관성을 유지하기 위해.
- 문제의 코드는 지침의 도입보다 이전에 있었고 해당 코드를 수정할 다른 이유가 없는 경우.
- 과거 버전의 파이썬으로 작성된 코드가 PEP 8 을 준수할 경우 작동하지 않아 과거 버전과 호환될 필요가 있을 경우.
