기본이 되는 내용이라고 할 수 있을거 같네요.
---------------------------------------------------
파이썬 스타일 지도서
Author: Guido van Rossum
translated into korean by johnsonj
XXX 서문.
바보같은 일관성은 골치거리이다.
스타일 지도서는 일관성에 관한 것이다. 이러한 스타일 지도서의 일관성은 중요하다. 프로젝트를 수행중일때는 더 중요하다. 하나의 모듈 혹은 함수안에서의 일관성은 더욱 중요하다.
그러나 대단히 중요한 것은 : 비일관적(inconsistent)이어야 할 때를 알도록 하라 -- 때때로 스타일 지도서는 단순히 적용되지 않는다. 의심스러울 경우에는, 여러분 자신이 최선의 판단을 하라. 다른 예들을 살펴보고 어떤 것이 가장 훌륭하게 보이는 지를 결정하라. 그리고 묻기를 주저 하지 마라!
차 례
- 전체보기 -- 탭, 공백, 그리고 새로운 라인을 사용하는 법.
- 주 석 -- 주석을 (그리고 문서화 문자열들을) 적절히 사용하는 법에 관하여.
- 이 름 -- 다양한 이름짓기의 관례들.
XXX 들어가기.
들여쓰기
Emacs의 파이썬 모드의 기본값을 사용하라: 한개의 들여쓰기 레벨당 4개의 공백을.
여러분이 혼란스럽지 않도록 진짜로 오래된 코드들에 대해서는 여러분은 8개 공백의 탭을 계속 사용할 수 있다.
Emacs의 파이썬 모드는 하나의 파일에 가장 많이 사용되는 들여쓰기 수준을 자동적으로 탐지해서 들여쓰기 매개변수를 그에 맞추어 설정한다.
탭인가 공백인가?
절대로 탭과 공백을 혼용하지 마라.
파이썬에서 가장 인기 있는 들여쓰기는 공백만을 사용하는 것이다. 두번째로 인기 있는 방법은 탭만을 사용하는 것이다.
탭과 공백을 혼용하여 들여쓰기된 코드는 공백만을 단독으로 사용하여 변환되어야만 한다.(Emacs에서는, 전체 버퍼를 선택하여 ESC-x를 쳐서 탭문자들을 없애라.)
-t 옵션으로 파이썬 명령어 해석기에 요청하면, 탭과 공백을 불법적으로 혼용한 코드에 대하여 경고를 보낸다. -tt 옵션을 사용하면 이러한 경고는 에러가 된다. 이러한 옵션들을 강력히 추천한다!
라인의 최대 길이
라인당 80자 언저리로 제한된 장치들이 여전히 많이 있다. 그러한 장치들에 대하여 기본으로 지정된 자동 줄넘기기는 보기에 흉하다. 그러므로, 모든 라인을 최대 79 문자로 한정하라(Emacs는 라인을 정확히 80자 길이에서 자동 줄넘기기를 한다.)
기다란 라인을 자동으로 줄넘기기에 선호되는 방법은 괄호, 각괄호, 대괄호안에서 파이썬의 묵시적인 라인의 연속을 이용하는 것이다. 필요하다면, 표현식 주위에 여분의 괄호 한쌍을 추가할 수도 있다, 그러나 어떤 때는 백슬래쉬를 사용하는 것이 더 좋게 보일 때도 있다. 연속된 라인을 적절히 확실하게 들여쓰기하라.
Emacs의 파이썬 모드는 이것을 정확히 수행한다. 약간의 예를 들면:
class Rectangle(Blob): def __init__(self, width, height, color='black', emphasis=None, highlight=0): if width == 0 and height == 0 and \ color == 'red' and emphasis == 'strong' or \ highlight > 100: raise ValueError, "sorry, you lose" if width == 0 and height == 0 and (color == 'red' or emphasis is None): raise ValueError, "I don't think so" Blob.__init__(self, widt, height, color, emphasis, highlight)
공백 라인들
최상위 함수와 클래스 정의는 두개의 공백 라인으로 분리하라. 한 클래스 안에서의 메쏘드 정의는 한개의 공백라인으로 분리된다. 여분의 공백라인은 관련된 함수들의 그룹들을 분리하는데 (아주 가끔) 이용되기도 한다. 공백라인은 한무리의 관련된 한라인 짜리 명령어 (예 : 일단의 비실행명령어)사이에서는 생략되기도 한다.
공백라인을 사용하어 메쏘드 정의를 가른다면, 'class'라인과 그 첫 번째 메쏘드 정의사이에 역시 하나의 공백라인을 둔다.
논리적 구별을 나타내기 위해서 함수에는 공백라인을, 아주 아껴서, 사용하라.
표현식과 서술문에서의 공백
신경쓰이는 것들
나는 다음과 같은 위치에서 공백문자를 사용하는 것을 아주 싫어한다 :
- 괄호, 각괄호 또는 대괄호 바로 안쪽 예를 들어:
spam(ham[ 1 ], { eggs: 2 } ).
이것을 항상 다음과 같이 쓴다 :spam(ham[1], {eggs: 2}).
- 컴마, 혹은 콜론, 세미콜론 바로 앞 예를 들어:
if x == 4 : print x , y ; x , y = y , x.
이것을 항상 다음과 같이 쓴다 : if x == 4: print x, y; x, y = y, x.
- 한 함수의 호출때 사용되는 인수리스트를 감싸는 왼괄호 바로 앞 예를 들어
spam (1).
이것을 항상 다음과 같이 쓴다 spam(1).
- 지표화나 썰기를 시작하는 왼괄호 바로 앞 예를 들어:
dict ['key'] = list [index].
이것을 항상 다음과 같이 쓴다 dict['key'] = list[index].
(위의 어떤 사항에 대해서도 나와 논쟁하려고 괴롭히지 마라 -- 나는 이미 15년간이나 이 스타일에 익숙해져 왔다.)
다른 추천사항
- 이진 연산자들은 양쪽에 한개의 공백으로 항상 두룬다 : 할당(=), 비교 (==, <, >, !=, <>, <=, >=, in, not in, is, is not), 불리언값(and, or, not).
- 수학적 연산자둘레에 공백을 삽입하는 것은 여러분이 판단하라. 항상 일관성있게 이진 연산자의 양쪽에는 공백이 있어야 한다. 약간의 예를 들면 :
i = i+1submitted = submitted + 1x = x*2 - 1hypot2 = x*x + y*yc = (a+b) * (a-b)c = (a + b) * (a - b)
- '='이 키워드 인수 혹은 기본 매변수값을 나타낼때 사용된다면 그 둘레에는 공백을 사용하지 마라.
예를 들어 : def complex(real, imag=0.0): return magic(r=real, i=imag)
코드에 배치되는 주석은 주석이 없는 것보다도 더 나쁘다. 코드가 변하면 항상 주석을 최신으로 먼저 유지하려는 노력을 하라!
주석이 구절이거나 문장이라면, 소문자로 시작하는 식별자가 아닌한 (절대로 식별자의 대소문자를 변경하지 마라!), 그것의 첫번째 단어는 반드시 대문자로 되어야 한다.
주석이 짧다면, 마지막의 구두점은 생략되는 편이 좋다. 블록 주석은 일반적으로 완전한 문장으로 이루어진 한개 혹은 그 이상의 문단들로 구성된다. 그리고 각 문장은 반드시 구두점으로 끝나야 한다.
여러분은 한 문장을 끝내는 구두점 다음에 두개의 공백을 사용할 수 있다.
영어를 쓸데처럼 언제나, 자신있게 공백을 적용하라.
영어를 사용하지 않는 나라의 파이썬 작성자들:
여러분의 언어을 사용하지 않는 사람들이 절대로 읽지 않을 것이라고 120% 확신하지 않는한, 영어로 주석을 작성하라.
블록 주석
블록 주석은 일반적으로 약간의 코드의 (또는 모두) 앞에 적용한다, 그리고 그 코드와 동일한 레벨에서 들여쓰기를 한다. 블록 주석의 각 라인은 (그것이 주석 안쪽의 들여쓰기된 텍스트가 아닌한) #와 한개의 공백으로 시작한다.
블록 주석안의 문단은 한개의 #을 포함한 공백라인으로 분리한다. 블록 주석은 위쪽 아래쪽으로 각각 한개의 공백 라인으로 둘려 싸여지는 것이 가장 좋다 (또는 새로운 함수정의 부분이 시작되는 곳에 있는 블록 주석에는 위쪽은 2개 아래는 1개의 라인이 좋다.).
라인 주석
라인 주석은 서술문과 같은 위치에 있는 주석이다. 라인 주석은 아껴서 사용해야만 한다.
라인 주석은 적어도 그 서술문으로부터 공백 2개로 분리해야 한다. 라인주석은 #와 공백한개로 시작해야만 한다.
라인 주석이 명백한 사실을 기술할때는 사실 산만스럽고 불필요하다. 이것을 사용하지 마라:
x = x+1 # Increment x
그러나 때로, 이럴때는 유용하다 :
x = x+1 # Compensate for border
문서화 문자열
모든 모듈은 보통 문서화 문자열을 가진다, 그리고 하나의 모듈이 수출한 모든 함수와 클래스 또한 문서화 문자열을 가진다. 공용 메쏘드 (__init__구성자를 포함하여) 또한 문서화 문자열을 가져야 한다.
한 스크립트(독자적 프로그램)에서 문서화 문자열은 "사용법" 메시지로 사용가능해야 한다. "사용법"은 스크립트가 부정확한 인수 혹은 인수를 빼먹고 (혹은 "-h"옵션을 "도움"을 위해 사용하여) 호출할 때 출력된다.
그런 문서화 문자열은 스크립트의 함수와 명령어 라인 구문, 환경 변수, 그리고 파일들에 대하여 문서화를 해 주어야만 한다. 사용법 메시지는 아주 우아하게 (몇개의 화면에) 치장할수도 있다 그리고 충분하게 새로운 사용자가 명령어를 적절히 사용할수 있도록 해 주어야만 할 뿐 아니라, 정밀한 사용자를 위해서 모든 옵션들과 인수들에 대한 완전한 참조를 제공하여야 한다.
일관성을 위하여, """ 세개의 이중인용부호"""를 문서화 문자열주위에 항상 사용하라.
두가지 형태의 문서화 문자열이 있다 : 한줄짜리 그리고 여러줄 문서화 문자열.
한줄짜리 문서화 문자열
한줄짜리 문서화 문자열은 진짜로 명백한 경우에 사용한다. 실제로 한줄에 딱 맞는다. 예를 들면:
def kos_root(): """Return the pathname of the KOS root directory.""" global _kos_root if _kos_root: return _kos_root ...
주의사항:
- 삼중 부호는 문자열이 한 라인에 맞을 때 조차도 사용한다. 이렇게 하면 나중에 확장하기에 편하다.
- 닫기 부호는 열기 부호와 같은 라인에 위치한다. 이렇게 해야 한줄짜리에는 더 좋아 보인다.
- 문서화 문자열의 앞 혹은 뒤에는 공백라인이 없다.
- 문서화 문자열은 구두점으로 끝나는 구절이다.
그것은 함수의 효과를 명령어로 ("Do this", "Return that")지시하는 것이지, 설명으로 지시하지는 않는다. : 예. don't write "Returns the pathname ..."
여러-줄 문서화 문자열
여러줄 문서화 문자열은 한줄 문서화 문자열과 똑 같은 요약 라인들로 구성되는데, 공백열이 하나 따르고, 다음에 더 자세한 설명이 따른다. 요약 라인은 자동적으로 인덱스를 하는 도구들에 의하여 사용되어진다;
요약라인은 한줄에 꼭 맞아야 하고 나머지 문서화 문자열들과 하나의 공백라인에 의하여 나누어진다는 사실은 중요하다.
전체 문서화 문자열은 첫 번째 라인에 있는 부호와 같은 위치에 들여쓰기 된다.( 아래의 예를 보라).
문서화 문자열의 처리 도구는 그 문서화 문자열의 첫 번째 라인 이후로 나타나는 첫 번째 비공백라인의 위치와 똑 같은 들여쓰기 위치로 두 번째 이후 라인으로부터 많은 양의 들여쓰기를 제거할 것이다. 문서화 문자열에 있는 이후의 라인들의 상대적인 들여쓰기는 유지된다.
여러줄 문서화 문자열의 가장 마지막 문단과 닫기 부호 사이에는 공백라인 하나를 삽입하기를 추천한다, 그리고 닫기 부호는 하나의 라인에 단독으로 놓기를 추천한다. 이런 식으로 , Emacs의 문단채우기 명령어가 사용될 수 있다.
나는 또한 모든 문서화 문자열(한-줄 혹은 여러-줄)앞과 뒤에는 한개의 공백라인을 두기를 권장한다.
문서화 문자열은 클래스를 문서화 하고 -- 일반적으로 말해서, 클래스의 메쏘드는 한개의 공백라인으로 각각 분리되고, 문서화 문자열은 그 첫번째 메쏘드로부터 한개의 공백 라인만큼 떨어질 필요가 있다 ; 균형을 위해, 클래스의 머리부와 문서화 문자열 사이에 한 개의 공백라인을 가지는 것을 선호한다. 함수를 문서화 하는 문서화 문자열은 함수의 몸체가 다수의 공백 라인으로 분리되어 씌여지지 않는 한, 일반적으로 이러한 요구사항을 갖지는 않는다. -- 이러한 경우에는, 문서화 문자열을 다른 섹션으로 다루고, 그것을 하나의 공백라인으로 대체하라.
하나의 모듈을 위한 문서화 문자열은 일반적으로 클래스, 예외 그리고 함수들 (그리고 다른 어떠한 객체들)에 대한 목록을 기술해야만 하는데 그것들은 각각에 대하여 한-줄 요약을 가지고, 모듈에 의하여 수출된다. (이러한 요약들은 일반적으로 객체의 문서화 문자열에 있는 요약 라인보다는 덜 상세하다.)
함수나 메쏘드를 위한 문서화 문자열은 그것의 행위를 요약해야만 하고 그것의 인수들, 반환값, 부작용, 예외상황 발생, 그리고 호출되었을 때의 제한 상황들에 대하여 문서화를 (가능하다면 모두) 해야만 한다. 선택적 인수는 명료하게 보여져야만 한다. 키워드 인수가 인터페이스의 부분인지 아닌지가 문서화 되어야 한다.
클래스를 위한 문서화 문자열은 그것의 행위를 요약하고 공용메쏘드와 실체변수들의 목록을 나열해야 한다.
만약 클래스가 하부 클래스가 된다면, 그리고 하부클래스와의 부가적인 인터페이스를 가진다면, 이러한 인터페이스는 각각 (문서화 문자열의 형태로) 나열되어져야만 한다. 클래스 구성자는 자신의 __init__메쏘드를 위하여 문서화 문자열로 문서화 되어야 한다. 각각의 메쏘드들도 자신들만의 문서화 문자열로 문서화 되어야 한다.
하나의 클래스가 또다른 클래스를 하부클래스로 가지고 그것의 행위가 거의 그 클래스로부터 상속된다면, 그것의 문서화 문자열은 이것을 언급해야만 하고, 그 차이를 요약해야만 한다.
"override" 동사를 사용하여 하부클래스의 메쏘드가 상위클래스의 메쏘드를 대체하고 그리고 그것를 호출하지 않는다는 것을 지시하라; "extend"동사를 사용하여 하부클래스의 메쏘드가 상위클래스의 메쏘드를 호출한다는 것을 (덧붙이자면 자신의 행위에) 지시하라.
실행중인 텍스트에서 대문자로 함수나 메쏘드의 인수를 언급하는 Emacs의 관례를 사용하지마라
파이썬은 대소문자를 구별하며 그리고 인수의 이름은 키워드 인수로 사용될 수 있다, 그래서 문서화 문자열은 정확한 인수의 이름을 문서화하여야 한다. 하나의 인수는 두개의 대쉬를 이름과 설명을 구분짓는데 사용하여, 각각 한 라인에 나열하는 것이 좋다. 다음과 같이:
def complex(real=0.0, imag=0.0): """Form a complex number. Keyword arguments: real -- the real part (default 0.0) imag -- the imaginary part (default 0.0) """ if imag == 0.0 and real == 0.0: return complex_zero ...
버젼 기록유지하기
여러분이 소스파일에 RCS 또는 CVS 표지를 가져야만 한다면, 다음과 같이 하라.
__version__ = "$Revision: 1.4 $"# $Source: /home/guido/ftp/pub/www.python.org/doc/essays/RCS/styleguide.html,v $
이 라인들은 모듈의 문서화 문자열 뒤에 포함되어져야만 하며, 다른 코드의 앞에는, 위 아래로 하나의 공백라인으로 구분해서 포함되어져야 한다.
파이썬 라이브러리의 이름짓기 관례는 약간은 혼란스럽다, 그래서 우리는 이것을 완벽하게 일관성이 있도록 하지는 못할 것이다.-- 그럼에도 불구하고, 여기에 약간의 가이드라인이 있다.
설명적인: 이름짓기 스타일
많은 수의 서로 다른 이름짓기의 스타일이 있다. 그것들이 무엇에 사용되는지로부터 각각, 어떤 이름 짓기 스타일이 사용되었는지를 알아낼수 있도록 도와 준다. 다음의 이름짓기 스타일은 일반적으로 자주 보는 것이다:
- x (한개의 소문자)
- X (한개의 대문자)
- lowercase (소문자)
- lower_case_with_underscores (밑줄로 연결된 소문자)
- UPPERCASE (대문자)
- UPPER_CASE_WITH_UNDERSCORES (밑줄로 연결된 대문자)
- CapitalizedWords (또는 CapWords) (단어의 첫자만 대문자)
- mixedCase (첫번째 문자가 소문자이므로 CapitalizedWords 와는 다르다!)
- Capitalized_Words_With_Underscores (보기 흉하다!)
또한 짧고 유일한 접두사를 사용하여 관계된 이름들을 무리짓는 스타일도 있다. 이것은 파이썬에서 많이 사용되지는 않지만, 완벽을 위해 언급한다. 예를 들어, os.stat() 함수는 하나의 터플을 돌려주는데 그 터플의 각 항목은 전통적으로 st_mode, st_size, st_mtime 등등과 같은 이름을 가진다. X11 라이브러리는 모든 공용 함수에 대하여 이끄는 X를 사용한다. (파이썬에서, 이러한 스타일은 일반적으로 불필요하게 생각된다. 속성과 메쏘드의 이름은 객체의 이름으로 접두어가 붙고, 그리고 함수의 이름은 모듈의 이름으로 접두어가 붙기 때문이다.)
게다가, 다음의 이끄는 혹은 끌리는 밑줄문자를 사용하는, 특별한 형태가 보인다. (이것들은 일반적으로 어떠한 경우의 관례와도 결합될 수 있다.):
- _single_leading_underscore: 약한 "내부 사용" 지시자 >
;(예. "from M import *" 은 밑줄문자로 시작하는 객체들을 수입하지 않는다). - single_trailing_underscore_: 파이썬의 키워드와의 충돌을 피하기 위하여 관례적으로 사용됨
예를 들어 : Tkinter.Toplevel(master, class_="ClassName"). - __double_leading_underscore: 파이썬 1.4에서의 클래스-사적인 이름들.
- __double_leading_and_trailing_underscore__: 사용자-제어 이름영역에 존재하는 "매력적인" 객체 혹은 속성 예를들어 : __init__, __import__ or __file__.
때때로 이것들은 사용자에 의해서 어떠한 매력적인 행위를 촉발하도록 정의된다. (예 : operator overloading);
때때로 이것들은 하부구조에 의해서 삽입되어져 디버깅 목적 혹은 자신만의 사용을 위해 쓰여진다. 하부구조(느슨하게 정의 하여 파이썬 인터프리터와 표준 라이브러리)는 미래의 버젼에 매력적인 속성들의 목록을 추가하기로 결정할 수 있다.
사용자 코드는 일반적으로 자기 자신만 사용하기 위하여 이런 관례를 사용하는 것을 자제해야 한다. 하부구조의 부분이 되기를 열망하는 사용자 코드라면 밑줄들 안에서 이것을 짧은 접두사와 결합할 수 있다.
예를 들어 : __bobo_magic_attr__.
지시적인: 이름짓기 관례
모듈 이름
모듈 이름은 MixedCase 이거나 lowercase 일 수 있다. 어떤 것을 사용할지 결정하는 명료한 관례는 없다. 한개의 클래스(혹은 많은 수의 밀접하게 연관된 클래스들, 또 약간의 부가적인 지원까지)를 수출하는 모듈은 가끔 MixedCase의 형태로 이름지어지며, 모듈의 이름으로 클래스의 이름도 동일하게 짓는다(예 : 표준 StringIO 모듈). 한 무리의 함수를 수출하는 모듈은 보통 모두 lowercase의 형태로 이름지어진다.
모듈의 이름은 화일의 이름에 사상이 되고, 어떤 화일 시스템은 대소문자를 구별하고, 긴 화일 이름을 잘라버리므로, 모듈의 이름이 아주 간결하게 선택되어야 하며 단지 다른 모듈이름과 대소문자만 달라서 충돌하지 말아야 한다. -- 이것은 유닉스에서는 문제가 되지 않는다, 그러나 코드가 맥이나 윈도우로 이식되면 문제가 발생할 것이다.
새로이 떠오르는 관례가 하나 있다. C 나 C++로 씌여진 확장모듈이 더 고수준의 (예를 들어 더욱 객체 지향적인) 인터페이스를 제공하는 파이썬 모듈을 동반할 때, 파이썬의 모듈 이름은 CapWords의 형태를 가지는 반면에, C/C++ 모듈은 모두 소문자로 이름짓고 하나의 이끄는 밑줄 문자를 가진다 (예를 들어 Tkinter/_tkinter).
"패키지"들은 ("ni"모듈이 지원하는, 모듈의 집합) 일반적으로 모두 소문자의 짧은 이름을 가진다.
클래스 이름
거의 예외없이, 클래스 이름은 CapWords 관례를 사용한다. 내부적인 사용을 위한 클래스는 부가적으로 이끄는 밑줄문자 하나를 사용한다.
예외 이름
하나의 모듈이 모든 종류의 조건들을 처리하기 위하여 하나의 예외(처리)를 정의한다면, 일반적으로 그것을 "error"혹은 "Error"라고 부른다. 내가 아는 한, 내장(확장) 모듈은 "error"(예를 들어 os.error)를 사용하는 반면에, 파이썬 모듈은 일반적으로 "Error"(예를 들어 xdrlib.Error)를 사용한다.
함수 이름
하나의 모듈에 의하여 수출된 단순한 함수는 CapWords 스타일을 사용하거나 lowercase (또는lower_case_with_underscores) 형태를 사용할 수 있다.
나는 특별히 선호하는 바는 없지만, 중요한 기능(예를 들어 nstools.WorldOpen())을 제공하는 함수에는 CapWords 스타일을 사용하고, 반면에 lowercase의 스타일은 "유틸리티"함수(예를 들어 pathhack.kos_root())에 더욱 많이 사용한다고 믿고 있다.
전역 변수 이름
(이런 변수들이 하나의 모듈안에서만 사용될것이라고 가정해보자.) 관례는 수출된 함수의 관례와 거의 동일하다. "from M import *"의 형식을 통하여 사용되도록 디자인된 모듈은 하나의 밑줄문자로 자신의 전역 변수 (그리고 내부 함수와 클래스)들에 접두사를 붙여서 그들을 수출하는 것을 막아야 한다.
메쏘드 이름
음, 이야기는 함수와 거의 동일하다. ILU를 사용할 때, 여기에 좋은 관례 하나가 있다 :
ILU 인터페이스를 통하여 발표된 메쏘드에는 CapWords를 사용하라. 객체형의 구현의 일부인, 다른 클래스 혹은 함수가 접근하는 메쏘드에는 소문자를 사용하라.
하부 클래스 혹은 상위 클래스의 속성들이 전혀 충돌하지 않거나 또는 하부 클래스 하나가 실제로 접근할 필요가 있을 때 "내부" 메쏘드와 실체 변수들에는 앞에 하나의 밑줄문자를 사용하라.
오직 현재의 클래스만이 하나의 속성에 접근하는 것이 중요할 경우에는 (클래스-지역 이름, 파이썬 1.4에서는 강제적임) 앞에 두개의 밑줄문자를 사용하라. (그러나 파이썬은 충분히 많은 루프구멍이 있어서 끈질긴 사용자는 그럼에도 불구하고 예를들어, __dict__ 속성을 통하여 접근할 수 있다. 오직 ILU 혹은 파이썬의 제한된 모드만이 XXX를 할것이다.
번역기간 : 2001.07.11 - 2001.07.15
현재버전 : 수 정 요 망
번 역 자 : 전순재
한글로 일단 바꾸고 생각해 본다.
내용은 본인도 잘 모름. 혹시 오역이 있으면 게시판에 알려주시면....고치겠습니다.
출처 : http://home.hanmir.com/~johnsonj/etc/Python%20Style%20Guide.htm
