Hubert: pep8

언어의 사전적 정의입니다.
언어란 한 사회의 구성원들 사이에 약속된 의사소통 규칙이자 오랜 세월 특유의 문화와 역사가 담긴 사회관습적 체계입니다.

누구나 모국어를 비롯해 외국어를 학습해 본 경험이 적어도 한번 즈음 있을 것입니다. 여러분들은 어떤식으로 접근하셨나요? 사회 구성원들과 생활하며 자연스럽게 익히기도 합니다. 단어와 문법을 차근차근 공부하며 체계적으로 언어에 대한 지식을 쌓아가기도 합니다. 어떤 방식을 사용하던지 최종 목표는 언어에 담긴 철학을 이해하고 자유롭게 구사하여 의사소통을 하는 것입니다.

프로그래밍 언어도 마찬가지입니다.
파이썬을 사용해서 코드를 작성하고 다른 사람과 의사소통 하려면 먼저 파이썬을 온전히 이해해야 합니다. 파이썬이 지나고 있는 철학은 무엇일까요?

Readability counts.

PEP20: The Zen of Python에서 19개 문장으로 파이썬의 철학을 설명하고 있습니다. 한 마디로 요약하면 Readability! 어느 누가 봐도 읽기 쉽고 간결한 파이썬 코드를 지향하고 있습니다.

PEP8은 무엇인가요?

파이썬 관련 문서를 검색하다보면 PEP라는 단어가 자주 출몰합니다. PEP는 'Python Enhancement Proposals'의 약자로 '파이썬 제안 사항' 정도로 이해할 수 있습니다. 파이썬의 새로운 기능이나 적용사항을 안내하거나, 일반적인 가이드라인이나 정보를 제공하는 역할을 담당합니다.

PEP8은 파이썬 창시자인 Guido van Rossum을 비롯하여 총 세 명의 저자가 작성했으며 Style Guide for Python Code에 대한 내용을 담고 있습니다. 일종의 코드 규칙을 제안함으로써 파이썬 코딩 컨벤션 ^{Python coding convention} 역할을 담당하고 있습니다. 이 외 다양한 파이썬 스타일 가이드 대부분 PEP8을 기반으로 하고 있으므로 반드시 알아두는 것이 좋습니다. PEP8 공식문서에서 세부내용을 확인할 수 있습니다.

A Foolish Consistency is the Hobgoblin of Little Minds

미국의 철학자이자 시인으로 활동한 Ralph Waldo Emerson의 'Self-Reliance'에 나오는 문장입니다. 원문은 아래와 같습니다.

"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."

"어리석은 일관성은 별 볼 일 없는 정치가와 철학자, 그리고 신학자들이 사랑하는 편협한 마음을 가진 홉고블린이다."

앞/뒤 문맥을 살펴보면 Emerson은 오늘 하는 말과 내일 하는 말이 모순될 지언정 다른 사람의 시선에 휘둘리지 말고 스스로 신뢰하는 자세가 사회를 지탱하고 더 나은 방향으로 나아가도록 만든다고 이야기 합니다. 사회의 정해진 규칙과 다른 사람이 옳다고 여기는 기준에 맞춰 바보같이 사는 것은 짓궃은 장난을 잘하는, 소인배 홉고블린에 지나지 않는다는 의미입니다. 이 사상은 오늘날 미국의 기둥이 된 개인주의 정신의 근간이 되었습니다.

파이썬 코드에서 가독성은 매우 중요합니다. 그러나 반드시 PEP8이 제시하는 가이드에 얽매일 필요는 없습니다. 더 가독성이 뛰어난 방식이 있다면 묻지도 따지지도 말고 그 방식을 선택하세요.

Code Lay-out: Indentation

하나의 indentation 레벨은 4개의 spaces를 사용합니다.

연속되는 라인은 괄호/중괄호/대괄호 내부에서 파이썬의 implicit line joining을 사용하여 래핑된 요소의 수직선 상에 맞추거나 hanging indent를 사용합니다. Hanging indent를 사용할 때는 첫 번째 라인에 인자들이 넣지 않습니다. 또한 예외적으로 4-space 규칙을 벗어날 수 있습니다. ( 예를 들어 2-space로 대체 )

PEP8: Indentation I

'if'문과 같은 조건문의 조건이 충분히 길어지는 경우, 괄호를 사용하여 멀티라인으로 작성합니다. 마찬가지로 4-space 규칙이 기본 적용되며 경우에 따라 추가 indent를 사용합니다.

PEP8: Indentation II

닫는 괄호/중괄호/대괄호는 멀티라인 중 마지막 라인의 첫 번째 글자와 동일선상에 맞추거나, 첫 번째 라인의 시작과 동일선상에 맞춥니다.

PEP8: Indentation III

Code Lay-out: Tabs or Spaces?

Space가 선호되는 방식입니다.

Tab을 사용하는 경우는 이미 코드에서 indent가 tab으로 작성된 경우입니다. 파이썬3에서는 space와 tab 혼용을 금지하고, 파이썬2에서는 혼용이 가능하지만 tab을 모두 space로 변환할 것을 강력히 권고합니다.

Code Lay-out: Maximum Line Length

모든 라인은 최대 79자 이내로 제한합니다.
Docstrings나 comments 같은 몇몇 구조들에서는 최대 72자로 제한합니다.

글자수를 제한하면 두 개 이상 코드를 editor로 열어서 동시에 작업할 수 있습니다. 눈으로 보기에도 더 깔끔한 코드를 작성할 수 있습니다.

멀티라인으로 작성할 경우 앞서서 언급한 indent 규칙을 준수하고 backslash를 사용합니다.

PEP8: Maximum Line Length

Code Lay-out: Should a Line Break Before or After a Binary Operator?

사칙연산기호와 라인 브레이크의 위치에 관한 내용입니다.
과거에는 사칙연산기호 이후에 라인 브레이크가 위치하는 스타일을 권장했습니다. 하지만 다음 두 가지 이유로 가독성을 떨어뜨립니다. 첫 번째로 연산기호들이 라인마다 다른 위치로 흩어집니다. 두 번째로 연산기호의 대상을 명확히 파악하기 어렵습니다. 아래 예시를 함께 보세요.

PEP8: Wrong! Line break and binary operator

하지만 수학에서는 전통적으로 사칙연산기호 이전에 라인 브레이크가 위치하는 스타일을 사용합니다. 가독성이 더 좋은 이 방식을 파이썬에서도 권장합니다.

PEP8: Correct! Line break and binary operator

Code Lay-out: Blank Lines

최상위 레벨 함수와 클래스 정의는 두 개의 공백라인으로 둘러쌉니다.

클래스 내부의 메서드 정의는 한 개의 공백라인으로 둘러쌉니다.

추가 공백라인은 관련된 함수들끼리 그룹으로 분리하는데 (아껴서) 사용할 수 있습니다.

추가 공백라인은 함수 내에서도 논리적 섹션을 나타내기 위해 (아껴서) 사용할 수 있습니다.

Code Lay-out: Source File Encoding

파이썬 배포판의 코드는 파이썬3인 경우 UTF-8, 파이썬2인 경우 ASCII를 사용합니다.
모든 파이썬 표준 라이브러리는 반드시 ASCII 식별자를 사용해야하고 언제나 사용 가능한 영어 단어를 사용합니다.
또한 테스트 케이스, 코드 작성자 이름 등과 같은 예외사항을 제외하면 모든 코드 내 문자와 코멘트는 ASCII를 사용합니다.

Code Lay-out: Imports

Import는 보통 라인별로 분리해서 진행합니다.

PEP8: Imports I

Import는 항상 파일의 제일 첫 부분에, 모듈 코멘트와 docstrings 바로 다음에, 그리고 모듈 전역변수와 상수 전에 위치해야 합니다.

다음 순서에 따라 그룹화 되어야 합니다.

1. 표준 라이브러리 imports
2. 연관된 써드 파티 ^{third party} imports
3. 로컬 응용프로그램/라이브러리 imports

각 그룹 사이에는 공백라인 한 개를 넣습니다.

Code Lay-out: Module Level Dunder Names

__all__, __author__, __version__ 등과 같은 모듈 레벨 "dunders" (두 개의 underbar가 앞/뒤 각각 붙는 명칭)는 모듈 docstring 이후 'from __future__' import를 제외한 다른 import문 이전에 위치해야 합니다.

PEP8: Module level dunder names

String Quotes

파이썬에서 작은따옴표와 큰따옴표는 동일하므로 어느 것을 권장하지 않습니다. 하지만 한 가지를 선택해서 사용하는 방식을 고수합니다.

PEP257의 내용에 다라 삼중따옴표는 항상 큰따옴표를 사용합니다.

Whitespace in Expressions and Statements: Pet Peeves

Pet Peeves의 의미를 영영사전에서 찾아보면, "Something that is maybe a bit annoying to most people but is very annoying or upsetting to a particular person."으로 설명하고 있습니다. 애완동물(Pet)이 대부분 사람들(most people)에게는 덜 짜증나는(a bit annoying) 존재이지만 특정 사람(particular person)에게는 매우 짜증나는 존재일 수 있습니다. 공백에 관한 규칙도 사소한 내용이지만 세세한 부분이 들어있다보니 누군가에게는 성가신 규칙이 될 수 있겠죠?

그럼에도 불구하고 아래와 같은 상황에서 추가적인 공백은 피하세요.

PEP8: Pet Peeves

Whitespace in Expressions and Statements: Other Recommendations

공백을 길게 늘려 사용하는 것은 대개 잘 보이지 않고 혼란을 초래할 수 있으니 피하세요.

다음 이진연산기호들은 항상 단일 공백으로 둘러쌉니다: 할당(=), 증강할당(+=, -=, etc), 비교(==, <, >, !=, <>, <=, >=, in, not in, is, is not), 논리(and, or, not)

만약 서로 다른 우선순위를 갖는 연산자들을 사용하면 가장 낮은 우선순위를 갖는 연산자를 공백으로 둘러쌉니다. 스스로 판단하되 한 개 이상의 공백은 절대 사용하지 말고 언제나 이진 연산자의 양 쪽 모두 같은 양의 공백을 사용합니다.

PEP8: Other recommendations I

함수 주석은 콜론에 대한 일반 규칙을 사용하고 -> 화살표가 있다면 항상 주위에 공백을 넣어야 합니다.

PEP8: Other recommendations II

키워드 인수나 기본 매개변수 값을 나타낼 때 사용하는 '=' 기호 주위에 공백을 사용하지 않습니다. 그러나 인자에 기본값을 할당할 때 사용하는 '=' 기호 주위에는 공백을 사용합니다.

PEP8: Other recommendations III

복합 명령문(한 라인에 여러개 명령문을 사용)은 사용하지 마세요.

PEP8: Other recommendations IV

When to Use Trailing Commas

후행 콤마는 요소가 한 개인 튜플을 생성할 때 필수인 경우를 제외하면 보통 선택사항입니다. 그리고 버전 제어 시스템이 사용될 때, 값이나 인자, 또는 임포트 된 항목들이 시간이 지남에 따라 확장될 것으로 추정될 때 도움이 됩니다. 사용방법은 각각의 값을 하나의 라인에 배치하고 항상 후행 콤마를 붙인 뒤 닫는 괄호/중괄호/대괄호를 다음 라인에 넣습니다.

PEP8: Trailing commas

Comments

코드와 모순되는 코멘트를 사용하느니 차라리 없는 것이 더 낫습니다. 언제나 코드가 변경될 때마다 코멘트를 최신으로 유지하는데 우선순위를 둬야합니다.

코멘트는 완성된 문장으로 작성해야 합니다. 첫 번째 글자는 대문자를 사용해야 하지만 식별자인 경우 소문자를 사용합니다.

블럭 코멘트 ^{Block comments}는 보통 완전한 문장으로 구성된 하나 이상의 단락으로 구성되며 각 문장은 마침표로 끝냅니다.

멀티- 문장 코멘트 내부에서는 각 문장이 끝날 때마다 두 개의 공백을 사용합니다. 단, 마지막 문장 다음에는 사용하지 않습니다.

영어를 사용할 때는 'Strunk and White'를 준수합니다. ('Strunk and White'는 영어작문의 기본서와 같은 'The Elements of Style(EOS)'을 지칭하는 단어입니다. 코넬 대학의 William Strunk Jr. 교수가 영문과 수업에 사용하기 위해 유인물 형태로 제작했는데 점점 대학교재처럼 사용되었습니다. Strunk 교수가 세상을 떠나고 그의 제자인 E. B. White가 이를 정식 책으로 출간하여 오늘날까지 미국 대학생들의 영어작문 기본서 역할을 하고 있습니다. 내용은 이 곳에 공개되어 있습니다.)

비영어권 파이썬 개발자들에게: 당신이 작성한 코드를 다른 나라 사람들이 절대 보지 않을 것이란 120% 확신이 없다면 코멘트를 영어로 작성하세요.

Comments: Block Comments

블럭 코멘트는 일반적으로 코멘트에 이어지는 일부 (또는 모든) 코드에 적용되며 그 코드와 동일한 레벨로 indent를 사용합니다. 각 라인은 '#'과 한 개의 공백으로 시작합니다. (코멘트 내부에 들여쓰기 된 텍스트는 제외)

블럭 코멘트 내부의 단락은 한 개의 '#'을 포함하는 라인으로 분리됩니다.

Comments: Inline Comments

인라인 코멘트 ^{Inline comments}는 아껴가며 사용하세요.

인라인 코멘트는 코드와 같은 라인에 존재하는 코멘트 입니다. 인라인 코멘트는 적어도 두 개 이상의 공백으로 코드와 분리되어야 하며 '#'과 한 개의 공백으로 시작합니다.

사실 인라인 코멘트는 필요하지 않고 명백한 내용을 명시하면 산만해 집니다. 이런 경우 사용하지 마세요.

Comments: Documentation Strings

좋은 docstring을 작성하기 위한 컨벤션은 PEP257에 영원히 남아있습니다.

모든 공개된 모듈, 함수, 클래스, 그리고 메서드에 대한 docstring을 작성하세요. 비공개 메서드는 작성할 필요는 없지만 어떤 역할을 하는지 정도는 코멘트로 작성해 주세요. 이 코멘트는 'def' 라인 다음에 나와야 합니다.

PEP257은 좋은 docstring 컨벤션에 대해 기술하고 있습니다. 가장 중요한 내용은 멀티라인 docstring의 끝에 나오는 """ 기호는 별도의 라인에 독립적으로 사용해야 한다는 것입니다. 단일라인 docstring은 """ 기호를 같은 라인에 사용합니다.

PEP8: Docstring

Naming Conventions

파이썬 라이브러리의 명명 컨벤션은 약간 엉망이므로 완전히 일관성을 유지할 수 없습니다. 그럼에도 불구하고 현재 권장되는 명명 기준을 소개합니다.

Naming Conventions: Overriding Principle

API의 공개적인 파트로써 이용자에게 보이는 명칭은 구현보다 사용방법을 반영하는 컨벤션을 준수합니다.

Naming Conventions: Descriptive - Naming Styles

정말 다양한 명명 스타일이 존재합니다.

명명 스타일은 보통 아래와 같이 구분됩니다.

⊙ b (single lowercase letter)
⊙ B (single uppercase letter)
⊙ lowercase
⊙ lower_case_with_underscores
⊙ UPPERCASE
⊙ UPPER_CASE_WITH_UNDERSCORES
⊙ CapitalizedWords: 또는 CapWords, CamelCase, StudlyCaps 등으로 불립니다. 울퉁불퉁한 모양 때문에 그런 이름이 붙었습니다.
⊙ MixedCase: 첫 글자가 lowercase라는 점에서 CapitalizedWords와 차이가 있습니다.
⊙ Capitalized_Words_With_Underscores: 못 생겼죠!

또한 연관된 이름을 그룹으로 묶기 위한 짧은 고유 접두사를 사용하는 스타일도 있습니다. 예를 들어 os.start() 함수는 st_mode, st_size, st_mtime 등의 이름을 가지는 아이템들을 튜플 형태로 반환합니다.

추가로 선행/후행 underscore를 사용하는 아래와 같은 형태로도 사용합니다. (일반적으로 어떤 컨벤션과도 함께 조합해서 사용할 수 있습니다.)

⊙ _single_leading_underscore: 약한"internal use"를 나타냅니다. 예를들어 'from M import *'는 underscore로 시작하는 이름을 가진 객체를 import하지 않습니다.
⊙ single_trailing_underscore_: 파이썬 키워드와 충돌을 피하기 위해 사용됩니다. 예를들어 'Tkinter.Toplevel(master, class_='ClassName')'
⊙ __double_leading_underscore: 클래스 속성을 명명할 때 name mangling을 호출합니다. (클래스 'FooBar' 내부에서 '__boo'는 '_FooBar__boo'가 됩니다.
⊙ __double_leading_and_trailing_underscore__: "magic" 객체 또는 사용자-제어 네임스페이스에 활성화 되어있는 속성에 사용합니다. 예를들어 '__init__', '__import__', 또는 '__file__'가 있으며 절대 동일한 이름을 사용하면 안됩니다.

Naming Conventions: Prescriptive - Names to Avoid

'l', 'O', 'I'는 단일 문자 변수명으로 절대 사용하지 않습니다.

일부 폰트에서 위 문자들은 숫자 '0', '1'과 구분이 불가능 할 수 있습니다.

Naming Conventions: Prescriptive - ASCII Compatibility

PEP3131의 정책 섹션에서 기술하는 것처럼 기본 라이브러리에서 사용하는 구분자는 반드시 ASCII와 호환 가능해야 합니다.

Naming Conventions: Prescriptive - Package and Module Names

모듈명은 모두 lowercase로 이루어진 짧은 이름을 가져야 합니다. 가독성을 향상시킬 수 있다면 모듈명에 underscore를 사용할 수 있습니다. 파이썬 패키지도 또한 마찬가지 규칙을 가지지만 underscore를 사용하지 않도록 권장합니다.

C나 C++로 작성된 확장 모듈이 높은 수준(예를들어 더 객체지향적인)의 인터페이스를 동반할 때, C/C+= 모듈은 선행 underscore를 가집니다. (예를들어 '_socker)

Naming Conventions: Prescriptive - Class Names

클래스 이름은 보통 CapWords 컨벤션을 준수합니다.

인터페이스가 문서화되어있고 주로 호출 가능한 형태로 사용되는 경우 함수들에 대한 명명 컨벤션이 대신 사용될 수 있습니다.

내장 함수들에 대한 별도의 컨벤션이 존재함을 기억하세요. 대부분 내장함수 명명은 하나의 단어 (혹은 함께 실행되는 두 개의 단어)로 이루어져 있습니다. 그러나 오직 예외 명명과 내장 상수들에서는 CapWords 컨벤션이 사용됩니다.

Naming Conventions: Prescriptive - Type Variable Names

PEP484에서 가져온 자료형 변수의 명명은 일반적으로 짧은 CapWords 사용을 선호합니다: T, AnyStr, Num. covariant나 contravariant behavior을 정의하려고 사용된 변수에는 각각 접미사 '_co', '_contra'를 사용할 것을 권장합니다.

PEP8: Type variable names

Naming Conventions: Prescriptive - Exception Names

예외는 클래스이므로 클래스 명명 컨벤션이 적용됩니다. 하지만 예외가 정말 error를 나타내는 예외명에 접미사 "Error"를 사용합니다.

Naming Conventions: Prescriptive - Global Variable Names

(전역 변수들이 오직 하나의 모듈 내에서만 사용하는 것으로 정해져 있기를 바라며) 함수들에 대한 동일한 명명 컨벤션이 적용됩니다.

'from M import *' 형태로 사용되도록 디자인 된 모듈은 전역 변수들을 내보내는 것을 방지하기 위해 '__all__' 메카니즘을 사용하거나, 혹은 전역변수에 underscore를 접두사로 사용하는 옛날 컨벤션을 사용해야 합니다.

Naming Conventions: Prescriptive - Function and Variable Names

함수명은 lowercase로 구성되어야 하며 가독성을 향상시키기 위해 단어는 underscore로 분리되어야 합니다.

mixedCase는 하위 버전과 호환성을 유지하기 위해 이미 잘 알려진 스타일 (예를들어 threading.py)의 컨텍스트 내부에서만 허용됩니다.

Naming Conventions: Prescriptive - Function and Method Arguments

인스턴스 메서드의 첫 번째 인자는 항상 'self'를 사용합니다.

클래서 메서드의 첫 번째 인자는 항상 'cls'를 사용합니다.

만약 함수의 인자명이 이미 예약된 키워드와 충돌한다면 약어나 스펠링을 망가뜨리는 것보다는 한 개의 후행 underscore를 추가하는 것이 일반적으로 더 낫습니다. 그러므로 'class_'가 'clss'보다 낫습니다. (이보다 더 좋은 방법은 동의어를 사용해서 충돌을 피하는 것입니다.)

Naming Conventions: Prescriptive - Method Names and Instance Variables

함수 명명 규칙을 사용하세요: 가독성을 향상시키기 위해 lowercase의 단어들은 iunderscore로 분리합니다.

비공개 메서드와 인스턴스 변수에는 오직 한 개의 선행 underscore만 사용합니다.

서브클래스와의 충돌을 피하기 위해서 두 개의 선행 underscore를 사용하여 파이썬의 name mangling 규칙을 호출합니다.

파이썬은 다음과 같은 이름을 클래스명으로 변환합니다: 만약 클래스 'Foo'가 '__a'라는 속성을 가지고 있다면 'Foo.__a' 방식으로 접근할 수 없습니다. ('Foo._Foo__a' 방식으로 강제적으로 접근할 수는 있습니다.) 일반적으로 두 개의 선행 underscore는 서브클래스로 디자인 된 클래스 안에서의 속성과 이름 충돌을 피하기 위한 목적으로만 사용해야 합니다.

Naming Conventions: Prescriptive - Constants

상수는 보통 모듈 수준에서 정의됩니다. 그리고 단어들은 underscore로 분리된 대문자를 사용합니다. 예를들어 'MAX_OVERFLOW', 'TOTAL'

Naming Conventions: Prescriptive - Designing for Inheritance

언제나 클래스의 메서드와 인스턴스 변수(통칭하여 "속성")의 공개/비공개 여부를 결정하세요. 만약 판단이 잘 서지 않는다면 비공개로 선택하세요; 비공개를 공개로 만드는 것이 더 쉽습니다.

공개 속성은 클래스와 상관없는 클라이언트가 사용할 것으로 기대되는 속성이며 하위 속성과 호환되지 않는 변경은 피하도록 약속해야 합니다. 비공개 속성은 써드파티에 의해 사용될 것으로 기대되지 않는 속성입니다; 비공개 속성은 변경되거나 심지어 삭제될 수 있습니다.

여기에서 "private"란 용어는 사용하지 않았으며, 실제로 파이썬에는 "private" 속성이 없기 때문입니다.

다른 속성의 범주는 "subclass API" (다른 언어에서는 종종 "protected"라고 불림)의 일부 파트가 되는 것입니다. 일부 클래스는 상속을 통해 클래스의 기능적인 측면을 확장하거나 수정해서 사용하도록 디자인 되었습니다. 그런 클래스를 디자인 할 때 어떤 속성이 공개인지, 어떤 속성이 subclass API인지, 그리고 어떤 속성시 정말 기본 클래스에 의해서만 사용되는지 정확하게 판단해야 합니다.

이를 명심하고 다음 파이썬다운 가이드라인을 참고하세요.

⊙ 공개 속성은 선행 underscore를 가지지 않습니다.
⊙ 만약 함수의 인자명이 이미 예약된 키워드와 충돌한다면 약어나 스펠링을 망가뜨리는 것보다는 한 개의 후행 underscore를 추가하는 것이 일반적으로 더 낫습니다. (하지만 이런 규칙이 있음에도 불구하고 'cls'는 클래스로 알려진 임의의 변수나 인자, 특히 클래스 메서드의 첫 번째 인자에 대한 명칭으로 사용됩니다.)
주의1: 클래서 메서드에 대해 앞에서 본 인자명 권장사항을 참고하세요.
⊙ 간단한 공개 자료 속성에 대해서 복잡한 접근자/변경자 메서드를 사용하지 않고 단지 속성명만 표시하는 것이 가장 좋습니다. 파이썬은 미래를 향한 개선을 위해 손쉬운 방법을 제공한다는 것을 기억한다면, 단순한 자료의 속성이 기능적 동작을 늘려가야 함을 알게 될 것입니다. 그런 경우 단순한 자료의 속성 접근구문 뒤에 프로퍼티를 사용하여 기능구현을 숨기세요.

주의1: 프로퍼티는 오직 새로운 스타일 클래스에만 작동합니다.

주의2: 비록 캐싱caching과 같은 사이드이펙트가 일반적으로 괜찮더라도 기능적 동작이 사이드이펙트로부터 자유로울 수 있도록 관리하려고 노력해야 합니다.

주의3: 계산비용이 많으 드는 프로퍼티 사용은 피해야 합니다; 속성 표기는 호출자가 접근이 쉽다고 믿도록 만듭니다.

만약 클래스가 서브클래스로 예약되어 있고 서브클래스에서 사용되지 않기를 바라는 속성이 있다면, 후행 underscore가 아니라 두 개의 선행 underscore를 사용해서 명명하는 것을 고려합니다. 이 방식은 파이썬의 name mangling 알고리즘을 호출하고 클래스명이 속성명으로 바뀝니다. 이는 속성명이 우연히 동일한 이름의 속성을 포함하고 있는 서브클래스와 충돌하는 것을 피하도록 도와줍니다.

주의1: 오직 단순한 클래스명만이 변경된 이름으로 사용된다는 것을 기억하세요. 따라서 만약 서브클래스가 동일한 클래스명과 속성명을 선택한다면 여전히 이름이 충돌할 수 있습니다.

주의2: Name mangling은 디버깅과 '__getattr__()'과 같은 류의 사용을 약간 불편하게 만들 수 있습니다. 그러나 name mangling 알고리즘은 문서화가 잘 되어있고 수동으로 쉽게 수행할 수 있습니다.

주의3: 모두가 name mangling을 좋아하지는 않습니다. 우연치않게 맞이하는 이름 충돌을 피해야 할 필요성과 숙련된 호출자에 의한 잠재적인 사용 가운데 균형을 맞추도록 노력해야 합니다.

Naming Conventions: Public and Internal Interfaces

모든 하위 호환성 보장은 단지 공용 인터페이스에만 적용됩니다. 따라서 사용자가 공용과 내부 인터페이스를 명확히 구별할 수 있는 것이 중요합니다.

문서에서 명시적으로 하위 호환성 보증으로부터 제외되는 임시 또는 내부 인터페이스로 분명하게 명시하지 않는 한, 문서화된 인터페이스는 공용으로 간주합니다. 문서화되지 않은 모든 인터페이스는 내부용으로 가정해야 합니다.

내부검사를 더 잘 지원하기 위해서 모듈은 '__all__' 속성을 사용하는 공개 API에서 이름을 확실하게 선언해야 합니다. '__all__'을 비어있는 리스트로 설정하는 것은 모듈에 공개 API가 없음을 나타냅니다.

'__all__'을 알맞게 설정하더라도 내부 인터페이스(패키지, 모듈, 클래스, 함수, 속성, 혹은 다른 이름)는 여전히 하나의 선행 underscore로 시작해야 합니다.

인터페이스가 포함하고 있는 어떤 네임스페이스(패키지, 모듈, 또는 클래스)가 내부 인터페이스로 간주된다면, 인터페이스도 내부 인퍼테이스로 간주합니다.

Import 된 이름은 언제나 세세한 구현을 고려해야 합니다. 다른 모듈이 포함된 모듈의 API에서 명시적으로 문서화 된 부분, 예를들어 os.path 또는 하위 모듈로부터 기능성이 노출된 패키지의 '__init__'과 같은 모듈, 이 아닌 이상 이렇게 import 된 이름에 대한 간접적인 접근에 의존해서는 안됩니다.

Programming Recommendations

다른 파이썬(PyPy, Jython, IronPython, CPython, Psyco 등과 같은) 구현에 불리하지 않은 방식으로 코드를 작성해야 합니다.

예를들어 'a += b' 또는 'a = a + b' 형식에서 CPython의 효과적인 내부 문자열 연결 구현에 의존하지 않습니다. 이 최적화는 CPython 안에서조차 깨지기 쉽고(이것은 오직 몇 가지 형태에 대해서만 작동합니다.) refcounting을 사용하지 않는 구현에서는 전혀 존재하지 않습니다. 대신 라이브러리에서 성능에 민감한 부분에서는 '.join' 형식을 사용합니다.이것은 다양한 구현에서 연결에 소요되는 시간이 일정하도록 보장합니다.

None과 같은 싱글레톤^singletons과의 비교는 언제나 'is' 또는 'is not'을 사용합니다. 절대 평등연산자를 사용하지 않습니다.

'not ... is'보다 'is not' 연산자를 사용합니다. 기능적으로 동일한 표현이지만 후자가 가독성이 좋고 더 선호되는 방식입니다.

PEP8: Programming recommendations I

다양한 비교와 함께 순서 나열하기 작업을 진행할 때, 오직 특정 비교만 실행하는 다른 코드에 의존하기보다 6개의 연산자('__eq__', '__ne__', '__lt__', '__le__', '__gt__', '__ge__')를 모두 구현하는 것이 가장 좋습니다.

식별자에 바로 람다 표현식을 붙이는 할당구문 대신 항상 'def' 구문을 사용합니다.

PEP8: Programming recommendations II

BaseException 보다 Exception으로부터 예외를 유도합니다. BaseException으로부터의 직접적인 상속은 예외를 발견하는 것이 대부분 잘못되는 경우를 위해 미리 예약되어 있습니다.

파이썬2에서 에러를 발생시킬 때, 예전 방식인 'raise ValueError, message' 대신에 'ValueError(message)'를 사용합니다.

'try/except' 절에서 'try' 절은 코드에서 최소로 제한합니다. 이 방식은 버그가 숨겨지는 것을 방지합니다.

PEP8: Programming recommendations III

'return' 구문은 일관성을 가져야 합니다. 함수에서 모든 'return'문이 표현식을 반환하거나, 모두 아무것도 반환하지 않거나 해야합니다. 만약 표현식을 반환한다면 값이 없는 'return'문은 'return None'을 반환해야 합니다. 그리고 'return'문은 가능하다면 명시적으로 함수의 가장 마지막에 위치합니다.

PEP8: Programming recommendations IV

접두사나 접미사를 체크하려면 문자열 슬라이싱 대신 ".startswith()"와 ".endswith()"를 사용합니다.

My Blog

Latest blog

파이썬 이해하기