Python Coding Convention(PEP8)

1. 코드 레이아웃

1.1 들여쓰기

들여쓰기 - 기본

- 한번의 들여쓰기에 4개의 스페이스를 사용하여야 한다.

- 괄호(대,중,소) 및 괄호안의 괄호와 같이 연결되는 라인에서 줄바꿈이 일어나는 요소들은 수직으로 정렬되어야 한다. (첫째 열에대한 규칙은 없으나 내어쓰기는 명확하게 구하도록 한다.)

 

예제 – 기본

좋은 예

# 여는 구분기호로 정렬되는 경우

foo = long_function_name(var_one, var_two,

var_three, var_four)

 

# 아랫줄과 구분을 위해 더 많은 들여쓰기 포함된 경우

def long_function_name(

var_one, var_two, var_three,

var_four):

print(var_one)

 

# 매달린 형태의 들여쓰기는 하나의 들여쓰기 레벨을 추가해야 함

foo = long_function_name(

var_one, var_two,

var_three, var_four)

 

나쁜 예

# 첫수직정렬이 안되어 있을때 첫째 줄은 금지되며 문제의 소지가 있음

foo = long_function_name(var_one, var_two,

var_three, var_four)

 

# 더 많은 들여쓰기가 필요한 경우, 함수안 첫째 줄과 구분이 어려움

def long_function_name(

var_one, var_two, var_three,

var_four):

print(var_one)

 

들여쓰기 - if 구문

- if 구문이 여러 줄을 사용할 정도로 길 경우, if, 여는괄호(, 스페이스 한칸은, 총 4개의 스페이스와 같은 길이를 만드므로 if 구문의 첫째 줄과 혼동을 일으킬 여지가 존재한다.

- PEP8에서는 이 문제에 대해 명확한 입장을 제시하지는 않으나 다음 예제와 같은 몇 가지 옵션을 제시한다.

 

if 구문에 대한 몇 가지 예

# 추가적인 들여쓰기가 없는 경우

if (this_is_one_thing and

that_is_another_thing):

do_something()

 

# 문법적으로 강조를 하여 if구문과 본문을 구분하기 위한 주석 추가

if (this_is_one_thing and

that_is_another_thing):

# Since both conditions are true, we can frobnicate.

do_something()

 

# 아랫 줄에 추가적인 들여쓰기

if (this_is_one_thing

and that_is_another_thing):

do_something()

 

# 경우에 따라 if문에 연산자가 추가될 경우 연산자 전 혹은 후에 줄바꿈을 할것인지에

# 대한 부분은 뒤에 연산자 부분 참고

 

들여쓰기 - 괄호(여러 줄)

- 기본에서 설명한 것보다 상세하게 설명하면, 닫는 괄호의 경우 마지막 줄의 첫번째 요소 바로 아래 맞추어도 된다.

- 혹은 공백 없이 라인의 가장 앞에 맞추어도 된다.

 

# 첫번째 요소 아래 맞추는 경우

my_list = [

1, 2, 3,

4, 5, 6,

]

result = some_function_that_takes_arguments(

'a', 'b', 'c',

'd', 'e', 'f',

)

 

# 라인의 가장 앞에 맞추는 경우

my_list = [

1, 2, 3,

4, 5, 6,

]

 

들여쓰기 - Tab과 스페이스

- 스페이스가 선호되는 내어쓰기 방법이다.

- 다만, 이미 과거에 작성된 코드에 적용되어 일관성을 유지할 필요가 있을 경우 탭을 사용해도 된다.

- Python3의 경우 탭과 스페이스의 조합은 문법적 오류를 야기한다.

- Python2의 경우 탭과 스페이스가 섞여있는 경우 탭이 스페이스로 변환되어진다.

- -t 옵션을 사용하여 Python 2 커맨드라인을 호출할 때, 스페이스와 탭을 섞어서 작성된 코드에 대해 경고가 뜬다.

- -tt 옵션을 사용하는 경우에서는 경고가 아니라 에러가 되며, 이 옵션이 추천된다.

 

1.2 한 줄의 최대 길이

- 한 줄의 최대 길이는 79 문자로 제한된다.

- 닥스트링이나 주석과 같이 구조적 제한이 적은 긴 텍스트 블럭을 처리하기 위해선, 한줄의 최대 길이는 72로 제한되어야 한다.

 

기대효과

- 사용되는 에디터의 윈도우 폭을 제한하여 여러 파일을 열어 겹쳐보는 것을 가능하게 한다.

- 이는 인접한 열에 두 버전을 제공하는 코드 리뷰툴을 사용할 때 작업효율을 개선한다.

- 대부분의 툴에서 기본 행바꿈은 코드의 가시적 구조를 파괴하여 이해하기 어렵게 만든다.

- 폭이 80글자로 세팅되어있는 윈도우 에디터 툴에서, 심지어 라인의 줄바꿈을 자동으로 해주는 상황에서도, 최대 줄수를 제한하는 것은 기본 행바꿈에 의해 구조가 파괴되는 상황을 피하기 위함이다.

- 몇몇의 웹 기반 툴은 동적인 자동 줄바꿈을 지원하지 않는다.

 

기타 사항

- 특정 팀들 한줄의 길이가 긴 것을 강력하게 선호한다. 이런 팀들에 의해 유지되는 코드에 대해서는, 주석이나 닥스트링은 여전히 72글자를 사용한다는 범위 내에서 코드의 길이를 80글자에서 100글자로 증가시키는 것도 허용된다.

- 파이썬의 표준라이브러리는 보수적이며, 79글자 이내로 제안하는 것을 요구한다.

(닥스트링과 주석은 72글자)

- 백슬래시(혹은 \, 원단위)를 활용하는 것은 매우 적절하다. 예를들어 매우 길며 여러줄을 사용하는 with구문은 계속적으로 사용할 수 없는데, 이 경우 백슬래시가 적용 가능하다.

 

예제

with open('/path/to/some/file/you/want/to/read') as file_1, \

open('/path/to/some/file/being/written', 'w') as file_2:

file_2.write(file_1.read())

(See the previous discussion on multiline if-statements for further thoughts on the indentation of such multiline with-statements.)

- 다른 예로는 assert 구문이 있다

- 연속되는 줄에서는 들여쓰기가 적절한지 확인하는 습관을 들이자.

 

1.3 이항연산자(binary operator)에서의 줄바꿈

- 수십년동안 추천된 스타일은 이항연산자 후에 줄바꿈을 하는 것이었다.

- 그러나 이것은 두가지 방법으로 가독성을 해칠 수 있다.

- 먼저 연산자는 스크린상에서 한열이 아니라 여러 열로 흩어지는 경향이 있다.

- 각각의 연산자는 피연산자 이후에 배치된다.

 

 

- 아래 이러한 상황을 살펴볼 수 있는 예가 있다.

 

예제

# No: operators sit far away from their operands

income = (gross_wages +

taxable_interest +

(dividends - qualified_dividends) -

ira_deduction -

student_loan_interest)

 

- 가독성 문제를 해결하기 위해 수학자와 출판자들은 위의 예와 반대인 표기법 사용한다.

- Donald Knuth는 그의 컴퓨터 타이핑세팅(Computers and Typesetting) 시리즈에서 전통적인 방법을 설명한다.

- “단락내의 수식들은 항상 이항연산자 이후에 줄바꿈이 되지만, 보여지는 수식은 항상 이항연산자 전에 줄바꿈이 된다."

- 수학자들의 전통을 따르는 아래의 예는 결과적으로 가독성이 더 좋은 코드를 만든다.

 

예제

# Yes: easy to match operators with operands

income = (gross_wages

+ taxable_interest

+ (dividends - qualified_dividends)

- ira_deduction

- student_loan_interest)

 

- Python 코드에서는 지역적으로 일관적인 표기법이 있는한 이항연산자 이전 혹은 이후에 줄바꿈을 하는 것이 허락된다.

- 새로 작성되는 코드에 대해서는 Knuth방식의 스타일이 추천된다.

 

빈줄

- 가장 높은 위치에 있는 함수와 클래의 정의 사이에는 2개의 줄바꿈을 사용하도록 한다.

- 클래스 내부의 메서드 정의는 위 아래로 줄바꿈을 사용하여 구분하도록 한다.

- 추가적인 빈줄은 연관된 함수들의 그룹을 분리하는데 사용된다.

- 줄바꿈은 한줄 짜리 묶음사이에서는 생략될 수 있다.

- 함수내에 논리 섹션을 나타내기 위해 빈줄을 사용할 수 있으나, 적당히 사용하도록 한다.

 

Control-L(^L) 폼피드 문자

- Python은 control-L(^L) 폼피드 문자를 공백으로 취급함. 많은 툴에서 이 문자를 페이지를 나눠주는 역할로 사용한다.

- 그래서 몇몇 사용자는 이 문자를 페이지를 나누는데 사용한다.

- 몇몇의 에디터들과 웹 기반 코드 뷰어들은 control-L문자를 폼피드로 인식하지 못하고 다른형태의 특수문자로 보여준다는 것을 참고하라.

 

1.4 소스파일 엔코딩

- 핵심 파이썬 배포판의 코드는 항상 UTF-8를 사용하여야한다. (혹은 Python2에서는 ASCII)

- ASCII(Python2) 혹은 UTF-8(Python3)을 사용하는 파일들은 엔코딩 선언을 해서는 안된다.

- 표준라이브러리에서는 기본값이 아닌 엔코딩은 오직 테스트목적이나 주석 및 닥스트링에 코드작성자 이름(ASCII 글자가 아닐 경우)을 언급할 때만 사용되어야 한다.

- 그외에는 \w, \u, \U 혹은 \N 확장키(escape)를 사용하는 것이 ASCII 데이터가 아닌 문자열을 포함하는 것에 대해 선호되는 방법이다.

- 파이썬 3.0 혹은 그이후의 버전에서는, 표준라이브러리에 대해 아래에 설명하는 정책이 미리 규정된다. (PEP 3131 참고할 것)

- 파이썬 표준라이브러리에서 사용되는 모든 식별자(identifier)는 반드시 ASCII 식별자만 사용하여야 하며, 실현가능한 곳에서는 영어 글자만 사용하도록 한다. (많은 경우에서 축약형이나 기술적인 용어의 경우에는 영어로 안쓰이는 경우가 있다.)

- String 문자열과 주석은 반드시 ASCII를 사용하여야만 한다.

- 예외적인 경우로 (a)ASCII 특성이 아닌 것을 테스트할때, (b)작성자의 이름. 라틴 알파벳(latin-1, ISO/IEC 8859-1 character set) 기반의 이름이 아닌 작성자는 반드시 이름의 음역(transliteration)을 제공하여야 한다.

- 전세계인이 참여하는 오픈소스 프로젝트에서는 이와 유사한 정책이 실행되고 있다.

 

1.5 Import

- import는 행으로 구분되어 사용되어야 한다.

 

좋은 예

import os

import sys

 

나쁜 예

import sys, os

 

- 아래의 경우는 사용해도 좋다.

 

from subprocess import Popen, PIPE

 

import의 위치 및 그룹화

 

- import는 항상 파일의 가장 위쪽에 모듈의 주석과 닥스트링 뒤에, 모듈 전역번수나 상수 전에 위치 시키도록 한다.

- import는 아래와 같이 그룹화 하도록 한다.

- 표준 라이브러리 import

- 관련된 서브파티 import

- 로컬 어플리케이션/자체라이브러리 import

- 위의 그룹 사이에는 빈 줄을 넣는 것이 좋다.

 

import의 사용

- 만약 import 시스템이 부정확하게 설정된 경우(예: 패키지 내부의 디렉토리가 sys.path로 끝나는 경우), 위처럼 그룹화가 된다면 읽기 쉬워지며 수정이 용이해지므로(error메세지 확인이 용이해진다.), Absolute import가 권장된다.

 

import mypkg.sibling

from mypkg import sibling

from mypkg.sibling import example

 

- 그러나, Absolute import를 사용하는 것이 쓸데없이 장황한 곳에서 복잡한 패키지 레이아웃을 다루고 있을때, Absolute import에 대해 Explicit relative import는 적용 가능한 대안이다.

 

from . import sibling

from .sibling import example

 

- 표준 라이브러리 코드는 복잡한 패키지 래이아웃을 피해야하며 항상 absolute import를 사용하여야 한다.

- Implicit relative import는 반드시 사용되지 말아야하고 Python3에서는 삭제된다.

- Class를 포함하고 있는 모듈에서 Class가 import되었을때, 아래처럼 쓰여지는게 가능하다.

 

from myclass import MyClass

from foo.bar.yourclass import YourClass

 

- 만약에 이런 작성이 로컬 네임과 충돌한다면 그럴경우 아래와 같이 작성되는 것이 좋다.

 

import myclass

import foo.bar.yourclass

# 그리고 “myclass.MyClas”와 "foo.bar.yourclass.YourClass"를 사용할 것.

 

Wildcard import

- Wildcard import(from <module> import *)는 네임스페이스에 존재하는 이름(변수, 함수, 클래스 등)이 명확하지 않고 코드를 읽는 사람과 자동화된 툴에게 혼동을 일으키므로 사용하지 않도록 한다.

- Wildcard import에 대해 사용이 용인될만한 예가있는데 그것은 public API의 일부로서 internal interface가 다시 개시된 경우이다.

- 예를들어 선택적 엑셀러레이터 모듈으로부터의 정의를 통해 인터페이스의 순수한 파이썬의 구현을 덮어 씌우는 것과 정확히 어떤 정의가 덮어 써진 것이 미리 알려지지 않았을 경우가 있다.

- 이 방법으로 이름이 다시 작성될때에는 아래의 Public과 internal interface 가이드라인이 적용 가능하다.

 

1.6 Module Level Dunder Names

- Module level “Dunders”(즉, __가 이름앞뒤로 쓰이는)(예: __all__, __author__, __version__, 기타등등) ,은 반드시 모듈 닥스트링 뒤에 쓰여져야 하고, from __future__ import를 제외하고 import문 전에 쓰여져야 한다.

- 파이썬에서는 future imports는 반드시 닥스트링을 제외하곤 다른 코드 전에 쓰여지는 것을 요구한다.

 

예제

"""This is the example module.

This module does stuff.

"""

 

from __future__ import barry_as_FLUFL

__all__ = ['a', 'b', 'c']

__version__ = '0.1'

__author__ = 'Cardinal Biggles'

 

import os

import sys

 

1.7 String Quotes(스트링 따옴표)

- 파이썬에서 따옴표 스트링과 쌍따옴표 스트링은 같다.

- 여기 PEP에서는 이것에 대한 권장사항을 만들지는 않음, 단지 규칙을 고수하고 그 규칙에 충실할 것을 당부드린다.

- 스트링에 따옴표 혹은 쌍따옴표를 포함하고 있을때, 스트링에 백슬래시를 피하기 위해 다른 하나를 사용하도록 한다.

- 3개의 (쌍)따옴표에 대해서는, 닥스트링 규칙(PEP 257)과 일관성을 유지하기 위해 항상 쌍따옴표를 사용하도록 한다.

 

1.8 표현식과 구문에서의 공백

Pet Peeves(눈엣가시)

- 아래 같은 상황에서 관계없는 공백은 피하도록 한다.

- 중괄호, 대괄호, 괄호 안.

좋은 예

spam(ham[1], {eggs: 2})

 

나쁜 예

spam( ham[ 1 ], { eggs: 2 } )

 

- 뒤에 오는 콤마와 오는 괄호 사이.

좋은 예

foo = (0,)

 

나쁜 예

bar = (0, )

 

- 콤마, 세미콜론, 혹은 콜론 전.

좋은 예

if x == 4: print x, y; x, y = y, x

나쁜 예

if x == 4 : print x , y ; x , y = y , x

 

- 슬라이스에서의 공백.

- 슬라이스에서 콜론은 이진연산자와 같이 적용되며, 양쪽에서 같은 크기를 가진다.

- 확장된 슬라이스에서는 두개의 콜론은 같은 간격을 가져야 한다.

- 예외적인 상황은 슬라이스 파라미터가 생략되거나 공간이 생략될 경우이다.

 

좋은 예

ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]

ham[lower:upper], ham[lower:upper:], ham[lower::step]

ham[lower+offset : upper+offset]

ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]

ham[lower + offset : upper + offset]

 

나쁜 예

ham[lower + offset:upper + offset]

ham[1: 9], ham[1 :9], ham[1:9 :3]

ham[lower : : upper]

ham[ : upper]

 

- 함수 불로오기의 변수리스트 시작을 알리는 여는 괄호 전에서의 공백.

좋은 예

spam(1)

 

나쁜 예

spam (1)

 

- 인덱싱 혹은 슬라이싱의 시작을 알리는 여는 괄호 전에서의 공백.

좋은 예

dct['key'] = lst[index]

 

나쁜 예

dct ['key'] = lst [index]

 

- 다른 변수와 줄맞춤을 위한 할당(혹은 다른) 연산자 주변의 하나를 초과하는 스페이스.

좋은 예

x = 1

y = 2

long_variable = 3

 

나쁜 예

x = 1

y = 2

long_variable = 3

 

1.9 다른 권장사항

- 어디서든 후행공백을 피하도록 한다.

- 이 후행공백은 시각적으로는 보이지 않기 때문에 혼란을 만들 가능성이 농후하다.

- 하나의 공백뒤에 백슬래시와 새로운 줄은 줄 연속메이커로 인식되지 않는다.

- 몇몇의 에디터들은 이것을 지키며 많은 프로젝트들은 사전 커밋 훅을 가지고 있다.

- 항상 주변의 하나의 스페이스로 이진연산자를 둘러 싸도록 한다.

- 할당연산자 : =

- 증가할당연산자 : +=, -=

- 비교연산자 : ==, <, >, !=, <>, <=, >=, in, not in, is, is not

- 불린연산자 : and, or, not

- 만약에 다른 우선순위의 연산자가 함께 쓰인다면, 가장 우선순위가 낮은 연산자 주변에 공백을 추가하는 것을 고려하며 본인의 판단을 사용하도록 한다.

- 그러나 하나 이상의 스페이스를 사용하지 말고, 항상 이진연산자 양쪽에 같은 양의 공백을 사용하도록 한다.

 

좋은 예

i = i + 1

submitted += 1

x = x*2 - 1

hypot2 = x*x + y*y

c = (a+b) * (a-b)

 

나쁜 예

i=i+1

submitted +=1

x = x * 2 - 1

hypot2 = x * x + y * y

c = (a + b) * (a - b)

 

- 키워드 독립변수(keyword argument) 혹은 기본 파라미터 값을 나타내기 위해 “=” 사인 주변에 스페이스를 사용하지 말도록 한다.

 

좋은 예

def complex(real, imag=0.0):

return magic(r=real, i=imag)

 

나쁜 예

def complex(real, imag = 0.0):

return magic(r = real, i = imag)

 

- 함수 주석은 콜론에 대해 일반적인 규칙을 사용해야하며, 항상 화살표 주변에 스페이스를 가져야 한다.

좋은 예

def munge(input: AnyStr): ...

def munge() -> AnyStr: ...

 

나쁜 예

def munge(input:AnyStr): ...

def munge()->PosInt: ...

 

- 함수의 기본값에서의 독립변수 주석을 합칠 때, = 사인 앞뒤로 스페이스를 사용하도록 한다.

(그러나, 오직 그가 주석과 기본값 둘 다 가질 경우만 해당된다.)

 

좋은 예

def munge(sep: AnyStr = None): ...

def munge(input: AnyStr, sep: AnyStr = None, limit=1000): ...

 

나쁜 예

def munge(input: AnyStr=None): ...

def munge(input: AnyStr, limit = 1000): ...

 

- 합성구문(Compound statements)(multiple statements on the same line)은 일반적으로 좋지 않다.

 

좋은 예

if foo == 'blah':

do_blah_thing()

do_one()

do_two()

do_three()

 

나쁜 예

if foo == 'blah': do_blah_thing()

do_one(); do_two(); do_three()

- 종종 if/for/while구문에서 같은 줄에 짧은 바디가 같이 놓이는 것은 괜찮지만, 여러 줄을 이런식으로 구성하는 것은 하지 않을 것을 당부함. 또한 위의 긴줄을 접는 것은 피하도록 한다.

 

나쁜 예

if foo == 'blah': do_blah_thing()

for x in lst: total += x

while t < 10: t = delay()

 

매우 나쁜 예

if foo == 'blah': do_blah_thing()

else: do_non_blah_thing()

try: something()

finally: cleanup()

do_one(); do_two(); do_three(long, argument,

list, like, this)

if foo == 'blah': one(); two(); three()

 

 

뒤에 오는 콤마(Trailing comma)를 사용할 경우

- 기본적으로 뒤에오는 콤마는 사용자의 선택이다.

- 하나의 튜플을 하나의 요소로 만들 때처럼 Trailing comma가 의무적으로 사용되어야 하는 상황은 제외된다.

- 파이썬 2에서는 print구문에서 의미를 가질 경우도 포함된다.

- 명확성을 위해, 의미없는 괄호로 문자를 덮는 것이 권장된다.

 

좋은 예

FILES = ('setup.cfg',)

 

사용해도 좋지만 헷갈리는 예

FILES = 'setup.cfg',

 

- 뒤에오는 콤마가 의미없는 상황에서, 콤마는 버전 컨트롤 시스템이 사용될 때 혹은 값의 리스트, 독립변수 혹은 imported된 item들이 확장될 것으로 예상될 때 상당히 도움된다.

- 패턴은 각각의 값을 그 라인 위에 놓아야하며, 항상 Trailing comma를 추가하여야 하고, 다음 줄에 닫는 괄호를 놓아야 한다.

- 뒤에 오는 콤마가 닫는 괄호처럼 같은 라인에 있어도 된다는 의미는 아니다.

(하나의 요소를 갖는 튜플은 제외된다.)

 

좋은 예

FILES = [

'setup.cfg',

'tox.ini',

]

initialize(FILES,

error=True,

)

 

나쁜 예

FILES = ['setup.cfg', 'tox.ini',]

initialize(FILES, error=True,)

 

2. 주석(Comment)

- 코드와 반대되는 주석은 주석이 없는 것 보다 더 좋지 않다.

- 항상 코드가 바뀌고 업데이트 될때 주석을 적는데 우선순위를 만들 것을 당부한다.

- 주석은 완전한 문장이어야 하며, 첫번째 글자는 소문자 식별자로 시작되지 않는 한 대문자로 적도록 한다.

- 마지막 문장을 제외하곤 문장이 끝에 두개의 스페이스를 사용하도록 한다.

- 영어를 쓸 때에는 “Strunk and White”(영어 글쓰기 책)를 따르도록 한다.

- 영어권 국가가 아닌 파이썬 개발자들은 당신이 코드가 국가 사람이 아닌 다른 사람이 읽지 않는다고 120% 확신하지 않는 한 당신들의 주석을 영어로 작성하도록 한다.(영어공부의 중요성...)

 

2.1 블럭 주석(Block comments)

- 블럭 주석은 일반적으로 완전한 문장의 조합인 하나 이상의 단락으로 구성되어 있다.

- 블럭 주석은 일반적으로 몇몇의(혹은 모든) 코드에 적용되며, 코드로서 같은 레벨로 들여쓰기가 되어진다.

- 각각의 블록코맨트 줄은 #와 하나의 스페이스로 시작한다.

(주석 안에서 들여쓰기가 경우가 아닌 경우)

- 블럭 코멘트 안쪽의 단락은 #를 포함함으로써 분리되어진다.

 

2.2 인라인주석(Inline Comments)

- 인라인주석은 적당히 사용하도록 한다.

- 인라인주석은 구문처럼 같은 라인에 있는 주석이다.

- 인라인주석은 구문으로부터 최소 2개의 스페이스로 구분되어야한다.

- 이것들은 #과 하나의 스페이스로 시작된다.

- 인라인주석은 필요하지 않으며 사실 명확하지 않으면 심란하게 만든다.

- 아래와 같이 하지 말것을 당부한다.

x = x + 1 # Increment x

 

- 그러나 아래와 같은경우는 종종 유용하다.

x = x + 1 # Compensate for border

 

2.3 닥스트링(Documentation Strings, Docstrings)

- 좋은 닥스트링(Documentation Strings)을 작성하는 규정은 PEP257을 참고하도록 한다.

- 모든 public 모듈, 함수, 클래스, 메소드에 대해 닥스트링을 작성한다.

- Non-public 메서드에 대해서는 닥스트링이 필요하지 않지만, 메서드가 어떤 역할인지 설명하는 주석을 적어야 하고, 이 주석은 def 라인 다음에 위치해야 한다.

- PEP 257에서 좋은 닥스트링 작성 규정에 대해 설명하고 있다.

- 가장 중요한 것은 여러줄로 구성된 닥스트링을 끝내는 “””는 혼자 있어야 함을 명심하도록 한다.

- 만약 한줄로 닥스트링이 작성된다면 닫는“””을 같은 줄에 놓아라.

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.

"""

 

3. 네이밍 작성 규칙

- 파이썬 라이브러리의 네이밍 작성 규칙은 다소 엉망이기 때문에, 완벽한 일관성은 힘들다.

- 그럼에도 불구하고, 여기 권장되는 네이밍 스탠다드가 있다.

- 새로운 모듈과 패키지 (서드파티 프레임워크를 포함하여)에서는 이 스탠다드에 맞춰 작성되어야 한다.

- 그러나 현재 다른스타일을 가지고있는 라이브러리가 존재하는 곳에서는 내부적으로 일관성 있게 하는 것이 선호된다.

 

가장 중요한 원칙

- API의 Public 파트로써 유저에게 보여지는 이름은 작성규칙을 실행(implementation)이 아닌 사용법을 반영하는 작성규칙을 따라야 한다.

3.1 표현(Descriptive): 네이밍 스타일

- 서로 다른 여러 네이밍 스타일이 존재하며, 어떤 스타일을 사용할 것인지 결정하는 것을 돕도록 한다.

- 아래의 네이밍 스타일은 일반적으로 널리 쓰이는 스타일이다.

- b (single lowercase letter)

- B (single uppercase letter)

- lowercase

- lower_case_with_underscores

- UPPERCASE

- UPPER_CASE_WITH_UNDERSCORES

- CapitalizedWords (CapWords, CamelCase, StudlyCaps으로 알려져있기도 하다.)

※ CapWord에서 줄임말을 사용할 때, 줄임말의 글자는 모두 대문자로 사용한다.

예를들어 HttpServerError보다는 HTTPServerError이 더 낫다.

- mixedCase (첫문자가 소문이기 때문에 CapitalizedWords 와는 다르다.)

- Capitalized_Words_With_Underscores (못생겼다..)

- 이외 고유한 짧은 접두사를 사용하여 그룹을 나타내는 스타일이 존재한다.

- 이것은 파이썬에서는 많이 사용되지 않으나, 문서의 완성도를 위해 언급된다.

- 예를들어, os.stat() 기능은 st_mode, st_size, st_mtime와 같이 전통적인 이름을 가진 튜플을 반환한다. (이것은 POSIX 시스템 호출 구조체의 필드와의 통신을 강조하기 위해 수행되며, 이 구조체는 프로그래머에게 익숙하다.)

- X11 라이브러리는 모든 이것의 public 함수에 대해 앞에 X를 사용한다.

※ 파이썬에서 오브젝트가 속성과 메서드 이름에 접두어로 붙고, 함수 이름에 모듈 이름이 접두어로 붙기 때문에 이 스타일은 일반적으로 필요하지 않다고 여겨진다.

- 추가적으로 앞 혹은 뒤에 _언더스코어를 사용한 아래의 특수 형태가 된다.

(일반적으로 어느 작성규칙에도 조합 가능하다.)

- _single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose name starts with an underscore.

- single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, e.g.

- Tkinter.Toplevel(master, class_='ClassName')

- __double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes_FooBar__boo; see below).

- __double_leading_and_trailing_underscore__: "magic" objects or attributes that live in user-controlled namespaces. E.g. __init__, __import__ or __file__. Never invent such names; only use them as documented.

 

3.2 규정(Prescriptive): 네이밍 규칙

 

피해야할 이름

- I(소문자, 엘), O(대문자, 오), 혹은 I(대문자, 아이)는 한글자 변수이름으로써 사용하지 말도록 한다.

- 몇몇의 폰트에서는, 이 글자들은 숫자 1 혹은 0과 구분이 쉽지 않으므로 l(소문자, 엘)을 사용할 때 L을 대신해서 사용하도록 한다.

 

ASCII 호환성

- ASCII PEP3131의 Policy section에서 설명되있는 것과 같이 표준 라이브러리에서 사용된 식별자는 ASCII와 호환이 가능하여야 한다.

 

패키지와 모듈 이름

- 모듈은 짧으며 모두 소문자인 이름을 가져야 한다.

- 언더스코어는 가독성을 향상시킬 수 있을 경우에 모듈의 이름에 사용될 수 있다.

- 파이썬 패키지의 이름 또한 짧으며 모두 소문자여야 하지만, 언더코어는 사용될 수 없다.

- C혹은 C++로 씌여진 확장 모듈이 높은 레벨(더욱 객채향적인) 인터페이스를 제공하는 파이썬 모듈을 가질때, C/C++ 모듈은 이름 앞에 언더스코어가 있어야 한다.

 

클래스 이름

- 클래스의 이름은 CapWords 작성규칙을 사용한다.

- 함수에 대한 이름 작성 규칙은 인터페이스가 문서화되고 주로 호출이 가능하게 사용되어질 경우 대신에 사용된다.

- 내장 이름에 대한 별도의 작성규칙이 있다.

- 대부분의 내장 이름은 하나의 단어(혹은 두 단어가 함께 실행됨)이다.

- 보통 예외이름(Exception name)과 내장 상수에 사용되는 CapWords 작성규칙이 사용된다.

 

타입 변수 이름

- PEP484에 소개된 타입 변수의 이름은 짧은 이름을 선호하는 CapWord방식을 사용한다.

- T, AnyStr, Num과 같이 공변(covariant)하거나 반변(contravariant)하는 거동을 선언하기 위해 사용되는 변수들에 대해서는 접미사 _co 혹은 _contra가 붙여지는 것이 권장된다.

 

from typing import TypeVar

VT_co = TypeVar('VT_co', covariant=True)

KT_contra = TypeVar('KT_contra', contravariant=True)

 

예외이름(Exception Names)

- 예외는 클래스어야 하기 때문에 클래스 이름 작성규칙은 여기에도 적용한다.

- 그러나 Error접미사를 예외 이름에 사용되게 된다. (예외가 에러일 경우)

 

전역 변수 이름

- 이 변수들은 하나의 모듈 안에서만 사용되기가 권장된다.

- 작성규칙은 함수에 대한 작성 규칙과 거의 비슷하다.

- from M import *를 이용하여 사용되게 설계된 모듈은 전역변수들을 exporting하기 위해 __all__ 매커니즘을 사용하여야 하며 혹은 언더스코어를 위의 전역변수 앞에 접두사로 붙이는 구식의 작성규칙을 사용하여야 한다.

 

함수 및 변수 이름

- 함수이름은 가독성을 개선시켜야하므로, 언더스코어로 구분된 소문자 단어로 구성된다.

- 변수이름은 함수이름과 같은 작성규칙을 따른다.

- mixedCase는 오로지 이전버전의 호환성을 유지할 필요가 있을 경우만 허락된다.

 

함수와 메서드의 독립변수

- 항상 인스턴트 메서드에 대한 첫번째 독립변수에는 self를 사용한다.

- 항상 클래스 매서드에 대한 첫번째 독립변수에는 cls를 사용한다.

- 만약 함수 독립변수의 이름이 사용된 키워드와 충돌한다면, 축약형 혹은 철자를 바꾸는 것보다 하나의 언더스코어를 끝에 덧붙이는 것이 일반적으로 더 좋게 만든다.

- class_가 clss보다 낫다. (더 나은 것은 동의어를 사용하여 충돌을 피하는 것이다.)

 

메서드 이름 그리고 인스턴스 변수

- 함수 네이밍 규칙을 사용하도록 한다.

- 가독성 개선을 위해 언더스코어로 구분된 소문자 단어들을 사용한다.

- Non-public 메서드와 인스턴스 변수에 대해서만 앞에 언더스코어를 사용한다.

- 서브클래스를 사용할 때 이름 충돌을 피하기 위해, 파이썬의 맹글링 규칙에 따라 변수 앞에 2개의 언더스코어를 사용한다.

- 파이썬은 클래스 이름과 함께 그 이름들을 심하게 훼손한다.

- 만약 클래스 Foo가 __a로 명명된 속성을 가진다면 이것은 Foo.__a로 접근할 수 없다.

(고집스런 유저라면 Foo._Foo__a을 호출함으로써 접근할 수 있다.)

- 일반적으로 변수앞 두개의 언더스코어는 서브클래스로 설계된 클레스에서 속성에 대해 이름 충돌을 피하기 위해 사용된다.

 

※ 참고사항: __ 이름에 대한 논란은 아직도 존재한다.

 

상수(constants)

- 상수는 모듈레벨에서 정의되고, 언더스코어로 구분되어 대문자로 작성된다.

- 예제: MAX_OVERFLOW , TOTAL

 

상속을 위한 설계

- 항상 클레스의 메서드와 인스턴스 변수가 public이되는지 non-public이 되는지 결정하도록 한다.

- 만약 확신하지 못한다면 non-public 으로 결정하는 것이 좋다. (public을 non-public으로 만드는 것보다 non-public을 public 속성으로 만드는 것이 더 쉽다.)

- Public속성은 사용을 위한 클래스의 관련없는 클라이언트라고 예상되는 것이며, 호환되지 않는 변경사항을 피하도록 노력한다.

- Non-public 속성은 서드파티에 의해 사용되지 않는 것이다.

- Non-public 속성은 바뀌지 않거나 제거되지 않는다는 것이 보장되지 않는다.

- 파이썬에서는 “private” 속성이 없기 때문에, “private”라는 용어를 여기서는 사용하지 않는다.

- 속성의 또 다른 카테고리는 서브클래스 API의 부분이다. (종종 “protected”라고 다른 언어에서 불림)

- 몇몇의 클래스는 클래스 기능의 수정과 확장을 위해 상속을 염두해 두고 설계된다. 위의 클래스를 설계할 때, 속성이 public이고, 서브클라스 API의 일부이고 기초클래스에 의해 사용되는 것에 관한 explicit 결정(decisions)을 만들 수 있음에 주의하도록 한다.

- 위와 관련하여 파이썬 다운 가이드라인이 아래에 제시된다.

- Public 속성은 이름앞에 _언더스코어를 가지지 않는다.

- 만약 public 속성 이름이 예약된 키워드와 충돌한다면, 이름 뒤에 하나의 언더스코어(_)를 붙이도록 한다. 이것은 축약형이나 스펠링을 파괴하는 것보다 선호되는 방법이다. (그러나, 여기 ‘cls’는 어떤 클래스로 잘 알려진 변수 혹은 독립변수에 대해(특히 클래스 메서드에서 첫번째 독립변수) 선호되는 스팰링이다.)

※ 참고 1: 위의 클래스 매서드에 대한 독립변수 이름 권장사항을 참고하도록 한다.

- 단순한 public 데이터 속성에 대해, 복잡한 접근자/유발자(mutator) 방법없이 속성 이름을 노출하는 것이 최고의 방법이다. 만약 당신이 단순한 데이터 속성이 기능적으로 향상되는 것을 필요로 할때, 파이썬은 미래의 향상에 대한 쉬운 경로를 제공함을 명심하도록 하라.

※ 참고 1: 특성,속성(Properties)는 세로운 스타일의 클래스에서만 작동한다.

※ 참고 2: Cahing과 같은 부작용은 일반적으로 괜찮지만 부작용이 없는 기능적인 일을 유지하도록 시도하도록 한다.

※ 참고 3: 계산적으로 상당한 작동을 요구하는 특성(Properties)을 사용하는 것을 피하도록 한다.

속성(attribute) 표기법은 호출자가 상대적으로 적은 비용으로 접근할 수 있게한다.

- 만약 클래스가 서브클래스화 되는 것이 고려될 때, 서브클래스에서 사용하길 원하지 않는 속성을 가지고 있다면, 이름 앞에 두개의 언더스코어를 활용하는 네이밍과 이름 끝에는 언더스코어를 작성하지 않는 것을 고려하도록 한다.

※ 참고 1: 단순한 클래스명은 맹글링된 이름에서 사용된다는 것을 참고하도록 한다.

만약에 서브클래스가 같은 클래스 이름과 같은 속성을 이름을 선택한다면, 여전히 이름 충돌을 가질 수 있다.

※ 참고 2: 이름 맹글링은 덜 편리한 디버깅과 __getattr__()과 같이 확실한 사용을 만들 수 있으나 이름 맹글링 알고리즘은 잘 서류화(documentated)되며 수행하기 쉽다.

※ 참고 3: 모두가 이름 맹글링을 좋아할 수는 없다. 향상된 호출자에 의한 잠재적 사용을 활용하여 이름 충돌을 피하기 위한 요구에 밸런스를 맞추는 것을 시도하도록 한다.

 

4. Public과 내부 인터페이스

- 이전버전과의 호환성 보장은 오직 public 인터페이스에게만 적용한다.

- 그런이유로, 유저들이 명확히 public과 내부 인터페이스 간을 구분할 수 있게 하는건 매우 중요하다.

- 이전 버전과의 호환성 보장을 하지 않는한 문서(Documentation)가 그들을 임시적 혹은 내부의 인터페이스라고 선언하지 않는한 문서화된(Documented) 인터페이스는 public을 고려한다.

- 모든 기록화(Documentated)되지 않은 인터페이스들은 내부에 있다고 가정된다.

- 검토를 더 낫게 하기 위해, 모듈은 이름을 public API 내부에서 __all__ 속성을 사용하여 선언해야한다.

- 빈 리스트에서의 __all__ 세팅은 모듈이 public API를 가지고 있지 않음을 나타낸다.

- __all__을 적당하게 사용하여, 내부 인터페이스(패키지, 모듈, 클래스, 함수, 속성 혹은 다른 이름들)은 하나의 언더스코어를 사용하여 접두어를 붙여야 한다.

- 만약 어느 네임스페이스(패키지 모듈 혹은 클래스)가 내부로 고려된다면, 어느 인터페이스도 내부로 고려된다.

- Import된 이름들은 항상 세부구분사항으로 고려되어야 한다.

- 다른 모듈은, 그들이 서브모듈로부터 기능을 보여주는 os.path 혹은 패키지의 __init__ 모듈과 같이 명시적으로 보유하고있는 모듈의 API를 문서화(Documentated)된 부분이 아니라면, 반드시 import된 이름에 대한 간접적인 접근에 의지해서는 안된다.

 

역자: 도대체 Documentation 혹은 Documentated가 의미하는바가 정확히 뭔지 모르겠다.

 

5. 프로그래밍 권장사항

- 파이썬의 다른 인터프리터(PyPy, Jython, IronPython, Cython, Psyco, 등..)에 불리하지 않은 방법으로 코드가 작성되어야 한다.

- 예를 들어, a+=b 또는 a=a+b 형식의 명령문에 대한 CPython의 내부 문자열 연결의 효율적인 구현에 의존해선 안됨. 이 최적화는 CPython에서도 취약하며(일부 유형에서만 작동 한다.) refcounting을 사용하지 않는 구현에서는 전혀 존재하지 않는다.

- 라이브러리의 성능에 민감한부분에 대해선 ‘’.join() 형태를 대신에 사용하여야 한다. 이는 다양한 실행에 걸처 선형시간에서 연속이 일어나게 한다.

- None과 같이 개체에 대한 비교는 equality operator가 아니라 반드시 is 혹은 is not과 함께 수행되야 한다.

- “if x is not None”을 사용할 때(None이 디폴트로 되어있는 변수 혹은 독립변수를 다른 값으로 세팅이 되는지 아닌지 테스트할 때) “if x”를 작성하는 것에 주의하도록 한다. (다른 값은 불린 context에서 false이 될 수 있는 타입을 가진다.)

- Not … is 보다는 Is not 오퍼레이터를 사용할 것. 두 표현식은 기능적으로 같으나, is not이 더욱 가독성이 좋다.

좋은 예

if foo is not None:

 

나쁜 예

if not foo is None:

 

- 다양한 비교를 사용하여 순서 지정 연산을 구현할 때에는, 특정 코드만 사용하여 다른 코드를 사용하는 대신 6가지 연산 (__eq__, __ne__, __ lt__, __le__, __gt__, __ge__)을 모두 구현하는 것이 가장 좋다.

- 위와 관련되어 투입되는 시간과 노력을 최소하기 위해, functools.total_ordering() 데코레이터는 누락된 비교 메소드를 생성하는 도구를 제공한다.

- PEP 207은 reflexivity 규칙이 파이썬에 의해 가정됨을 나타냄. 따라서, 인터프리터는 y> x와 x <y, y> = x를 x <= y로 바꾸고 x == y 및 x! = y의 인수를 서로 바꿀 수 있다.

- sort () 및 min () 연산은 <연산자를 사용하도록 보장되며 max () 함수는> 연산자를 사용하나 그러나 다른 상황에서 혼동이 발생하지 않도록 6가지 작업을 모두 구현하는 것이 가장 좋다.

- 람다 표현식을 식별자에 직접 바인드하는 할당문 대신에 항상 def 문을 사용하도록 한다.

 

좋은 예

def f(x): return 2*x

 

나쁜 예

f = lambda x: 2*x

 

- 첫번째 형태는 결과함수 오브젝트의 이름이 ‘<lambda>’가 아니라 ‘f’ 인 것을 의미한다.

- 일반적으로 트레이스백과 문자열(string) 표현에 대해서는 이것이 더 유용하다.

- 할당문의 사용은 람다표현식이 제공하는 def구문보다 더 유리한 장점을 제거한다.

(즉 더 큰 표현식에 포함될 수 있다.)

- BaseException보단 Exception으로부터 예외를 얻도록 한다.

- BaseExcepction으로부터의 직접적인 상속은 예외를 잡는 것이 거의 항상 잘못되는 경우를 위해 남아있다.

- 예외가 발생하는 위치가 아니라 예외를 잡는 코드가 필요할 수 있는 구분을 기반으로 예외 체계를 설계하도록 한다.

- “문제가 발생했다” 라고 시작하는 것보다는 “무엇이 문제로 이끄는가”에 대한 질문에 대답하는 것을 목표로 하도록 한다(내장예외계층에 대해 설명하는 PEP 3151을 참고하라.)

- 예외가 에러인 상황에서 당신의 예외클래스에 “Error” 접미사를 더하더라도, 클래스 네이밍 작성규칙은 여기를 적용하도록 한다.

- 비로컬 흐름 제어 또는 다른 형태의 시그널링에 사용되는 에러가 없는 예외는 접두사를 붙일 필요는 없다.

- 예외 체인을 적절히 사용하도록 한다.

- 파이썬 3에서, “raise X from Y”는 오리지날 트레이싱을 잃어버리지 않고 explicit replacement를 나타낼 때 사용된다.

- 의도적으로 내부 예외(파이썬2에서는 “raise X” 사용하거나 파이썬 3.3+에서는 “raise X from None”를 사용하여)가 교체될 때, 관련 세부 사항이 새로운 예외(예: KeyError를 AttributeError로 변환 할 때 속성 이름을 유지하거나 원래 예외의 텍스트를 새로운 예외 메시지에 포함하는 경우)로 전송되는지 확인하도록 한다.

- 파이썬 2에서 예외가 나타날때, “raise ValueError, 'message'”와 같이 오래된 형태보다는 “raise ValueError(‘message’)를 사용하도록 한다.

- 전자의 경위 Python3에서는 문법적으로 맞지 않다.

- paren-using형식은 에외 독립변수가 길거나 문자열 포맷을 포함하고 있을때 포함된 괄호덕에 연속문자를 사용할 필요가 없다는 것을 의미한다.

- 예외를 선정할 때, 가능하다면 except:를 사용하는 것 보단 특정한 예외를 언급하도록 한다.

try:

import platform_specific_module

except ImportError:

platform_specific_module = None

- bare except:절은 컨트롤C를 사용하여 프로그램을 중단시키는 것을 어렵게 만드는 SystemExit와 KeyboardInterrupt 예외를 잡을 수 있고, 다른 문제를 숨길 수 있다.

- 만약 사용자가 모든 예외를 잡길 원한다면 except Exception:를 사용하도록 한다.

(bare except는 except BaseException:과 동일하다.)

- 가장 좋은 규칙은 아래의 두 케이스에서 bare ‘except’ 구문의 사용을 제한하도록 한다.

1. 만약 예외 핸들러가 트랙백을 출력하거나 로그를 만든다면, 최소 사용자는 에러가 났다는 것을 알 것이다.

2. 만약 코드가 정리작업 필요하다면, 그러나 그때에 예외가 raise를 사용해서 다음에 전파하지 못하게 만든다.

try...finally가 이런 케이스를 다루기 위해서는 더 나은 방법이다.

- 이름에 대해 발견된 예외를 바인딩할때, 파이썬 2.6에서 추가된 explicit 이름 바인딩 문법을 선호하도록 한다.

try:

process_data()

except Exception as exc:

raise DataProcessingFailedError(str(exc))

- 이것은 파이썬 3에서만 지원되는 구문이고, 오래된 콤마 기반 구문과 연관된 애매한 문제들을 피하게 할 수 있다.

- 작동 시스템 에러를 잡을때, errno 값의 인트로 스팩션을 통해 파이썬 3.3에서는 explicit 예외 계층을 선호하도록 한다.

- 모든 try/except 구문에 대해, try 구문의 절대적인 수를 최소한으로 제한하도록 한다.

- 다시 설명하면, 이것은 버그를 감출수 없게 한다.

 

좋은 예

try:

value = collection[key]

except KeyError:

return key_not_found(key)

else:

return handle_value(value)

 

나쁜 예

try:

# Too broad!

return handle_value(collection[key])

except KeyError:

# Will also catch KeyError raised by handle_value()

return key_not_found(key)

 

- 리소스가 코드의 특정한 섹션에 위치할때, 이것이 사용 이후에 즉시 그리고 신뢰성있게 정리되는 것을 보장하도록 “with”구문을 사용하도록 하거나, 혹은 try/finally 구문 역시 적용할만하다.

- 리소스를 얻거나 제공할때를 제외하고는 어떤 것을 할때든 별도의 함수 혹은 메서드를 통해 콘텍스트 매니저는 호출되어야 한다.

 

좋은 예

with conn.begin_transaction():

do_stuff_in_transaction(conn)

나쁜 예

with conn:

do_stuff_in_transaction(conn)

 

- return 구문에서 일관성을 유지하도록 한다.

- 함수에 있는 모든 return 구문은 반드시 표현식을 반환하거나, 없어야한다.

- 만약 어떤 return 구문이 표현식을 반환했다면, 어떤 return 구문이 반환되는 값이 없는 곳에서는 “return None”을 명시하고, 함수의 끝에 (만약 도달할 수 있다면) explitict return 구문이 존재해야한다.

 

좋은 예

def foo(x):

if x >= 0:

return math.sqrt(x)

else:

return None

 

def bar(x):

if x < 0:

return None

return math.sqrt(x)

 

나쁜 예

def foo(x):

if x >= 0:

return math.sqrt(x)

 

def bar(x):

if x < 0:

return

return math.sqrt(x)

 

- 문자열 모듈 대신에 문자열 메서드를 사용하도록 한다.

- 문자열 메서드는 항상 빠르고, 유니코드 문자열을 사용하여 같은 API를 공유한다.

- 만약 파이썬 2.0보다 더 오래된 이전 버전과의 호환성이 요구된다면 이 역할을 무시하도록 한다.

- 접두사 혹은 접미사를 확인하기 위해서는 문자열 슬라이싱 대신에 ''.startswith()과 ''.endswith()를 사용하도록 한다.

- startswith()과 endswith()는 더 명확하며 에러가 덜 발생하기 쉽다.

 

좋은 예

if foo.startswith('bar'):

 

나쁜 예

if foo[:3] == 'bar':

 

- 오브젝트 타입 비교는 항상 직접적으로 타입을 비교하는 것 대신 isinstance()를 사용하여야 한다.

 

좋은 예

if isinstance(obj, int):

 

나쁜 예

if type(obj) is type(1):

 

- 오브젝트가 문자열인지 아닌지 확인할 때에는, 이것이 유니코드 문자열이어야 한다는 것을 명심하도록 하라.

- 파이썬 2에서는 str과 유니코드는 공통 베이스 클래스(basestring)를 가진다.

 

if isinstance(obj, basestring):

- 파이썬 3에서는 Unicode, basestring 더이상 존재하지 않으며(오직 str만 존재한다.), 바이트개체는 더이상 문자열의 종류가 아니다. (대신 정수 시퀀스이다.)

- 시퀀스(문자열, 리스트, 튜플)에 대해, 비어있는 시퀀스는 false라는 것을 사용하도록 한다.

 

좋은 예

if not seq:

if seq:

 

나쁜 예

if len(seq):

if not len(seq):

 

- 상당한 후행공백에 의존하는 문자열을 리터럴을 작성하지 말도록 한다.

- 후행공백은 시각적으로 구분되지 않고 몇몇의 에디터들(혹은 최근에는 reindent.py)에게 후에 제거될 수도 있다.

- 불린 값을 True 혹은 false에 ==을 사용하여 비교하지 말도록 한다.

 

좋은 예

if greeting:

 

나쁜 예

if greeting == True:

 

더 나쁜 예

if greeting is True:

 

5.1 함수 주석

- PEP484를 수용하면, 함수 주석에 대한 스타일 규칙은 바뀐다.

- 이후 버전과의 호환성을 위해, 파이썬 3에서 함수주석은 PEP 484 문법을 사용하는 것이 권장된다.

(이전 섹션에 주석에 대한 포맷 권장사항이 있으므로 이를 참고하라.)

- 이전에 이 PEP에서 추천되었던 주석스타일에 대한 실험은 더 이상 권장되지 않는다.

- 그러나 stdlib의 밖에서는, PEP484의 규칙 내에서의 실험은 현재 권장된다.

- 예를들어 PEP 484스타일 주석을 사용하는 서드파티 라이브러리나 어플리케이션을 마크업하는 것과, 쉽게 주석을 리뷰하는 것, 그들의 존재 여부를 관찰하는 것은 코드에 대한 이해도를 개선시킨다.

- 파이썬 표준라이브러리는 위의 주석을 시도하는 것에 보수적이다.

- 그러나 그것들의 사용은 새로운 코드 그리고 대형 재작성(refactoring)에서 허락하도록 한다.

- 다른 형태의 함수주석을 만들기를 원하는 코드에 대해선 아래와 같은 형태의 주석을 달아 놓는 것이 권장된다.

# type: ignore

- 파일의 가장 위 부근에서, 이것은 Type checker에게 모든 주석이 무시됨을 의미한다.

(Type checker로부터의 불만을 제거할 좋은 방법은 PEP 484에서 찾을 수 있다.)

- Type checker는 선택사항이며 별도의 툴이다.

- 기본 파이썬 인터프리터는 타입 확인에 의한 어떤 메세지도 발행하지 않으며 주석에 기반한 그들의 행동을 고쳐서는 안된다.

- Type checker를 사용하는 것을 원하지 않는 사용자가 Type checker를 무시하는 것에 대해서는 자유이다.

- 그러나 서드파티 라이브러리 패키지의 사용자들이 그들의 패키지를 사용하여 Type checker를 작동시키는 것이 예상되며, 이런 목적에 대해 PEP484는 stub 파일의 사용을 추천한다.

- Type checker가 해당 py파일을 사용하여 읽을 수 있는 Pyi 파일,Stub 파일은 라이브러리 혹은 별도의 (라이브러리 작성자의 허가가 있을 때) typeshed repo(유형이 지정된 저장소)를 통해 구분되어질 수 있다.

- 이전버전과의 호환성이 필요한 코드에 대해서는, 주석(comment) 형태의 타입 주석(annotation)이 추가될 수 있고, PEP 484의 관련된 섹션을 참고하라.

 

5.2 변수 주석

- PEP 526는 변수주석을 소개하는 문서임. 변수에 대한 스타일 권장사항은 위에 설명된 함수주석과 유사하다.

- 모듈 레벨 변수, 클래스와 인스턴스 변수, 지역변수에 대한 주석은 콜론 이후 하나의 스페이스를 가진다.

- 콜론 전에는 스페이스가 없다.

- 배정이 오른쪽이라면, 그때에는 이퀄리티 사인은 양쪽에 하나의 스페이스를 가져야 한다.

 

좋은 예

code: int

class Point:

coords: Tuple[int, int]

label: str = '<unknown>'

 

나쁜 예

code:int # No space after colon

code : int # Space before colon

class Test:

result: int=0 # No spaces around equality sign