about PEPs

Life is short. You need Python.

PEPs란?¶

Python 커뮤니티에는 PEP(Python Enhancement Proposals)라는 것이 있다. Python이라는 언어의 발전을 위해 논의된 결과들을 문서화 해둔 것인데, 한번쯤 읽어두면 좋은 파이썬 프로그래머가 되는데 도움이 되지 않을까 한다.

물론 따르지 않아도 혼자 작업하고 작동하는 결과물을 만들어내는데에는 아무 문제 없지만, 그래도 되도록이면 한번쯤 읽어볼만한 가장 중요한 문서 2개를 소개해보려고 한다.

1. PEP 20 - The Zen of Python¶

파이썬의 핵심 철학에 대해 정리한 문서로, 파이썬을 설치하면 내장 모듈로 설치된다. 내용을 확인하고 싶다면 Python에서 this를 임포트 해보자

>>> import this

그러면 아래와 같은 결과가 나온다.

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

시적이기도 한 내용이 나오는데, 아마도 이런 철학이 python만의 pythonic한 문화를 만드는데 기반이 되지 않았을까 한다.

2. PEP 8 - Style Guide for Python Code¶

PEP 20이 Python의 기본 철학이라면, PEP 8은 Pythonic한 코드란 어떤 코드인지에 대한 실질적인 권고들을 정리한 문서다. 한번쯤 읽어두면 Python의 장점인 가독성을 살리는 코딩 스타일을 알 수 있다.

사실 메모장 수준의 편집기가 아니라면 어지간해서는 자동으로 PEP 8에 따라 코딩하도록 기본 설정이 되어 있는데, 내용이 꽤 많아 여기서는 주요 내용 몇 가지만 정리한다.

2-1. 탭 vs 스페이스¶

인던트를 넣을 때는 탭 대신에 스페이스를 사용하자.
탭은 이미 탭으로 인던트 되어 있는 문서를 수정할 때만 사용한다.
- 파이썬은 인던트에 탭과 스페이스를 섞어서 사용하는 것을 허용하지 않는다.

2-2. 한 줄 최대 길이¶

한 줄의 최대 길이는 79자로 한다.
매우 긴 string의 경우(긴 문장이나 문단 수준)에는 72자를 한 줄의 최대 길이로 한다.

2-3. 이항연산과 줄바꿈¶

여러 줄에 걸쳐 이항연산이 이루어질 때는, 가독성을 위해 연산자가 줄바꿈 뒤(다음 줄의 맨 처음)에 들어가야 한다.

# 좋은 예
y = (x1
    + x2)

2-4. 빈 줄¶

최상위 함수와 클래스들에 대한 정의는 두 줄의 빈 줄로 감싼다.
클래스 안의 메서드들을 구분할 때는 한 줄의 빈 줄로 구분한다.
함수 안에서의 빈 줄은 논리 단위를 구분할 때 사용한다.

2-5. imports¶

각각의 모듈들은 따로따로 임포트 되어야 한다. 하지만 하나의 모듈에서 여러 하위 모듈을 임포트 할 때는 한 줄로 임포트 가능하다.
임포트는 언제나 파일의 맨 위, 모듈의 docstrings/comments 다음, 전역 변수 이전에 위치해야 한다.
임포트 순서는 아래와 같으며, 각각의 그룹 사이에는 빈 줄이 들어가서 구별되어야 한다.
내장 모듈
연관된 서드 파티 모듈
local 자체 모듈

# 좋은 예
import os
import sys

from subprocess import Popen, PIPE

import mymodule

임포트는 절대 참조가 권장되지만, 절대 참조할 경우 너무 내용이 길어지는 복잡한 수준의 패키지 작업에서는 상대 참조도 용납된다.

2-6. string 따옴표¶

하나로 통일만 한다면 ', " 어느 것을 써도 상관 없다.

2-7. 띄어쓰기와 관련된 권고들¶

다음과 같은 논리연산자들은 양 옆에 띄어쓰기로 구별해준다.
- assignment: =
- augmented assignment: +=, -= etc.
- comparisons: ==, <, >, !=, <>, <=, >=, in, not in, is, is not
- Booleans: and, or, not
이항연산자 주위의 띄어쓰기의 좋은 예는 아래와 같다.
- 기본적으로는 이항연산자 앞뒤에 띄어쓰기를 넣어주는게 권고되지만, 우선순위가 있을 경우 우선순위가 높은 것 끼리는 붙여써도 된다.

# 좋은 예
i = i + 1
submitted += 1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

메서드에 들어가는 keyword argument를 정의하는 =의 경우에는 띄어쓰기를 넣지 않는게 좋다. 하지만 type hint와 같이 사용할 때는 =를 스페이스로 감싸주는게 좋다.

# 좋은 예
def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ...

2-8. 주석 관련 권고들¶

inline comment를 작성할 때는 코드와 최소 두 칸 띄어서 써야한다.
Docstring을 작성할 때는 반드시 """triple double quotes"""를 사용해야 한다.

2-9. Naming 관련 권고들¶

module의 이름은 반드시 짧고, 모두 소문자로 이루어져 있어야 한다. _의 사용은 권장되지는 않지만, 가독성을 제고하기 위해서 사용할 수 있다.
class의 이름은 CapWords를 써야 한다.

# 좋은 예
class TestClass: ...

함수와 변수들의 이름은 소문자로 한다. 단어 분리가 필요한 경우 _를 사용한다.
모듈 레벨에서 정의되는 Constants들의 경우 대문자를 사용한다.

2-10. 프로그래밍 관련 권고들¶

boolean 자료형을 ==를 사용해서 True, False와 대조하지 마라.

# 좋은 예
if greeting:

# 나쁜 예
if greeting == True:

# 더 나쁜 예
if greeting is True: