PEP가 뭐길래? (What the PEP?)

파이썬을 사용하다 보면 종종 만나는 단어가 바로 "PEP"이다.

특히, 코딩 스타일 관련해서 매번 만나는 "PEP 8" 규칙.

 

과연, PEP가 뭐길래?

 

▶ PEP Created

- 1990년대 후반 CNRI에 있던 Barry Warsaw(배리 워쇼우)가 많은 제안들을 Guido가 살펴볼 수 있도록 프로세스 도입
- RFC(Request for Comments, 인터넷 기술 및 표준에 관한 문서) 프로세스를 참조하여 (제안 → 토론 → 결론) 체계 수립

 

다양하게 파생된 '-EP' 문서들

 

 

▶ PEP 0 - Index of Python Enhancement Proposals (PEPs)

- PEPs로 알려진 모든 PEP 목록을 살펴볼 수 있게 제공해준다.
- 다양한 기준으로 PEP 목록을 제공해준다.

 

 

 

 

▶ PEP 8 – Style Guide for Python Code

- 파이썬 답게 코드를 작성하기 (Pythonic Code)

- PEP 중에서 가장 유명하고, 필독해야 하는 문서

- 들여쓰기는 4개의 공백(space)을 사용해야 한다는 것과 같은 코드 스타일 가이드 이다.

 

 

 

▶ PEP 572 – Assignment Expressions

- Guido를 독재자에서 사임하게 만들었던 문제의 그 PEP

- 일명 바다코끼리 연산자(walrus operator) ":=" 도입
  . 할당 표현식(assignment expression)
  . Python 3.8에 포함

- Guido가 제안한 내용이고 도입을 하자는 입장이었고, 커뮤니티는 파이썬 답지 않고, 간결성을 해친다며 반대

- 결국은 승인되어 파이썬 3.8에 도입되었지만, Guido는 BDFL 모델을 내려놓게 되었고

  이후 "The Steering Council Model"을 통해 의사결정 하기로 함 (PEP 8016)

 

 

 

▶ PEP 20 – The Zen of Python

- 파이썬의 선 (파이썬이 추구하는 철학)

 

아름다운 것이 못생긴 것보다 좋습니다. 명시적인 것이 암시적인 것보다 좋습니다. 단순한 것이 복잡한 것보다 좋습니다. 복합적인 것이 복잡한 것보다 좋습니다. 납작한 것이 중첩된 것보다 좋습니다. 흩뿌려진 것이 모인 것보다 좋습니다. 가독성은 중요합니다. 특별한 상황이, 규칙을 깰 만큼 특별하단 얘기는 아닙니다. 실용성이 순수함을 이길 때까지는 말이죠. 에러는 조용히 넘어가서는 안됩니다. 명시적으로 조용히 만들지 않는 한. 모호한 상황이라면, 추측하려 하지 마세요. 문제를 풀 수 있는 (바람직하고 유일한) 분명한 방법이 있어야 합니다. 하지만 네덜란드 인이 아닌 이상 처음에는 분명하지 않을 수 있습니다. 지금 하는 게 하지 않는 것보단 좋습니다. 하지만 지금 당장 하는 것보다 안 하는 게 나을 때도 있습니다. 구현 방식이 설명하기 어렵다면, 그것은 좋지 않은 생각입니다. 구현 방식이 설명하기 쉽다면, 그것은 아마 좋은 생각일 겁니다. Namespaces는 쩌는 생각입니다. 더욱 이런 것들을 해봅시다!

 

※ 중간에 네덜란드 사람이라고 지칭하는 이유는... 귀도가 네덜란드 사람이라서이다 ^^

 

 

 

[ 참조/참고 ]

- Python PEP, 태어나 세계로 퍼진 ‘○EP’ 이야기: https://news.hada.io/topic?id=21031 
- Paul Everitt, "Python 1994", PyBay2017: https://www.youtube.com/watch?v=7NrPCsH0mBU&t=1662s 
- PEPs & Co.: https://hugovk.dev/blog/2025/peps-and-co/ 

- PEP 0: https://peps.python.org/pep-0000/ 

- PEP 8: https://peps.python.org/pep-0008/ 

- PEP 572: https://peps.python.org/pep-0572/ 

- PEP 20: https://peps.python.org/pep-0020/