52 | 프로그램에서 다양한 종류의 에러가 많이 일어날 수 있다. 디버깅을 해서 에러를 더욱 신속하게 추적해 들어가려면 에러의 종류를 구별하는 것이 좋다:
53 |
54 |
55 |
56 |
57 | 구문 에러는 소스 코드를 파이썬 코드로 번역할 때 파이썬이 만들어 낸다. 구문에러는 보통 프로그램의 구문에 무엇인가 문제가 있다는 것을 나타낸다. 예: def 서술문의 마지막에 쌍점을 빼 먹는 것.
58 |
59 |
60 | 실행시간 에러는 프로그램이 실행되는 동안에 무엇인가 잘못된다면 실행시간 시스템이 만들어 낸다. 대부분의 실행시간 에러 메시지는 에러가 일어난 곳과 어떤 함수가 실행되고 있었는지에 대한 정보를 포함하고 있다. 예: 무한 재귀는 결국 "최대 재귀 깊이를 초과하는" 실행시간 에러를 야기한다.
61 |
62 |
63 | 의미구조 에러(Semantic errors)는 프로그램이 컴파일되고 실행되지만 정확한 일을 수행하지 않을 때 발생하는 문제이다. 예: 하나의 표현식이 예상한 순서대로 평가되지 않아서, 결과적으로 예상치 못한 결과를 산출하는 것.
64 |
65 |
66 |
67 |
68 | 디버깅의 첫 번째 단계는 어떤 종류의 에러를 처리해야 하는지 알아내는 것이다. 다음 섹션은 에러의 종류에 따라서 조직되었지만, 어떤 테크닉들은 여러 상황에 적용될 수 있다.
69 |
70 |
71 |
구문 에러(Syntax errors)
72 |
73 | 구문에러는 그 에러가 무엇인지 알기만 하면 보통 쉽게 수정할 수 있다. 불행하게도 에러 메시지는 보통 도움이 되지 않는다. 가장 흔한 메시지는 "SyntaxError: invalid syntax"와 "SyntaxError: invalid token"인데 둘 다 별로 정보를 주지 않는다.
74 |
75 | 그렇기는 하지만 구문에러 메시지는 문제가 프로그램의 어디에서 일어났는지 말해 준다. 실제로 구문에러 메시지는 파이썬이 문제를 인지한 곳을 알려 주는데, 반드시 에러가 있는 곳일 필요는 없다. 어떤 때는 에러 메시지의 위치 앞에 에러가 있기도 하며, 어떤 때는 바로 앞 줄에 있을 수도 있다.
76 |
77 | 만약 프로그램을 점증적으로 구축하고 있다면, 구문에러가 어디에 있는지 확실하게 알수가 있다. 구문에러는 마지막으로 추가한 바로 그 줄에 있을 것이다.
78 |
79 | 책에서 코드를 복사했다면 제일 먼저 복사된 코드를 책에 있는 코드와 아주 주의깊게 비교하자. 모든 문자들을 점검하라. 동시에 그 책이 틀릴 수도 있다는 것을 기억하자. 그래서 만약 구문 에러처럼 보이는 어떤 것을 발견한다면, 그것이 바로 구문에러일 것이다.
80 |
81 | 다음은 가장 흔하게 구문에러를 유발하는 원인들을 피하기 위한 방법이다:
82 |
83 |
파이썬 키워드를 변수 이름으로 사용하고 있지는 않은지 확인하라.
84 |
모든 복합 서술문의 머리부에서 끝에 쌍점(colon)을 가지고 있는지 점검하라. 다음의 for, while, if, 그리고 def 서술문들을 포함한다.
85 |
86 | 들여쓰기가 일관성이 있는지 점검하라. 공백이나 탭을 함께 사용하여 들여쓰기 해도 좋지만, 그 둘을 혼합하여 사용하지 않는 것이 최선이다. 각 수준은 같은 양의 들여 쓰기로 내포되어야 한다.
87 |
88 | 코드에 있는 모든 문자열이 짝을 이뤄 인용 부호를 가지고 있는지 확인하라.
89 |
90 | 만약 삼중 (홑 또는 겹) 따옴표로 여러 줄에 걸친 문자열이 있다면, 그 문자열을 적절히 끝마쳤는지 확인하라. 끝나지 않는 문자열은 프로그램의 마지막에서 "무효한 토큰(invalid token)" 에러를 야기하거나, 또는 그 프로그램에서 이후 부분을 다음 문자열에 다다를 때까지 문자열로 취급해 버릴 수도 있다. 이 경우에는 에러 메시지를 전혀 산출하지 않을 것이다!
91 |
92 | 닫혀지지 않은 괄호---(, {, 또는 [--- 때문에 파이썬은 다음 줄을 현재 서술문에 이어진다고 간주하고 계속해서 처리한다. 일반적으로 이 에러는 다음 줄에서 거의 즉시 일어날 것이다.
93 |
94 | 조건문 안에서 == 대신에 고전적인 =을 사용하고 있는지 점검하라.
95 |
96 |
97 |
98 |
만약 아무 문제도 없으면 다음 섹션으로 나아가라...
99 |
100 |
어떻게 해도 프로그램을 실행시킬 수 없어요.
101 |
102 | 컴파일러가 에러가 있다고 말해주는데도 불구하고 그것을 이해하지 못하는 상황이라면 여러분과 컴파일러가 같은 코드를 보고 있는 것이 아니기 때문일 가능성이 있다. 여러분의 환경을 점검하여 편집하고 있는 프로그램이 파이썬이 실행하려고 하는 그 프로그램인지 확인하라. 확신할 수 없다면, 프로그램의 시작부분에 의도적으로 확실한 구문 에러를 배치하여 보라. 이제 그것을 다시 실행(혹은 반입) 하라. 만약 컴파일러가 그 새로운 에러를 발견하지 못하면, 아마도 여러분의 개발환경이 설정되는 방식에 무엇인가 잘못이 있다는 뜻이다.
103 |
104 |
105 |
실행시간 에러(Runtime errors)
106 |
107 | 이 시점에서는 구문적으로 정확한 파이썬 코드로 이루어진 파일을 가지고 있다. 파이썬은 프로그램을 반입할 수 있고 그것을 실행할 수 있다. 무엇이 잘못될 수 있을까?
108 |
109 |
프로그램이 아무것도 하지 않아요.
110 |
111 | 이 문제는 거의 대부분 파일이 함수와 클래스로 구성되어 있으며 실제로는 무엇엔가 실행을 시작하도록 요청하지 않을 때이다. 이 모듈을 반입하여 클래스와 함수만을 공급할 계획이라면 이것은 의도적일 수 있다.
112 |
113 | 의도적인 것이 아니라면 상호대화 프롬프트에서 함수에 실행을 시작하도록 요청하거나 또는 함수에 함수를 실행하도록 요청하고 있는지 확인하라. 또 아래에 있는 "실행의 흐름(Flow of Execution)" 섹션을 참조하라.
114 |
115 |
프로그램이 멈춰요.
116 |
117 | 프로그램이 중지하고 아무것도 하지 않는 듯이 보인다면, 그것을 "목이 매달려있다(hanging)"고 말한다. 이 말이 뜻하는 바는 종종 무한 회돌이 또는 무한 재귀에 빠졌다는 것을 뜻한다.
118 |
119 |
120 |
121 | 특정한 회돌이가 문제라는 의심이 든다면, print 서술문을 그 회돌이의 바로 앞에 추가해서 "회돌이에 들어감"이라고 출력하게 하고 바로 뒤에 또 하나를 추가하여 "회돌이를 빠져나감"이라고 출력하게 하라
122 |
123 | 프로그램을 실행하라. 두 번째 메시지가 아니라 첫 번째 메시지를 만나면 무한 회돌이에 빠진 것이다. 아래에 있는 "무한 회돌이" 섹션으로 가라.
124 |
125 | 무한 재귀에 빠지면 프로그램은대부분 잠시동안 실행되다가 "실행시간에러: 최대 재귀 깊이를 초과함(RuntimeError: Maximum recursion depth exceeded)"이라는 에러를 출력할 것이다. 그런 일이 일어나면 아래의 "무한 재귀" 섹션으로 가라.
126 |
127 | 이러한 에러를 만나지 않을 지라도 재귀 메쏘드 또는 재귀 함수에 문제가 있다고 의심된다면, 여전히 "무한 재귀" 섹션에 있는 있는 테크닉을 사용할 수 있다.
128 |
129 | 두 단계 어느쪽도 문제가 없으면, 다른 회돌이 그리고 다른 재귀 함수와 메쏘드의 테스트를 시작하라.
130 |
131 |
132 | 이 단계에서도 작동하지 않으면, 프로그램의 실행 흐름을 이해하고 있지 못할 가능성이 있다. 아래에 있는 "실행의 흐름" 섹션으로 가라.
133 |
134 |
135 |
136 |
무한 회돌이(Infinite Loop)
137 |
138 | 무한 회돌이를 가지고 있다고 생각하고 어떤 회돌이가 문제를 야기하고 있는지 알고 있다면, print 서술문을 그 회돌이의 마지막에 추가하여 그 조건안에 있는 변수들의 값을 출력하고 그 조건의 값을 출력하라.
139 |
140 |
예를 들어:
141 |
142 |
143 |
while x > 0 and y < 0 :
144 | # x에 대해 무언가 처리한다.
145 | # y에 대해 무언가 처리한다.
146 |
147 | print"x: ", x
148 | print"y: ", y
149 | print"condition: ", (x > 0 and y < 0)
150 |
151 |
152 |
153 | 이제 프로그램을 실행할 때, 회돌이를 돌 때마다 세 줄의 출력을 볼 것이다. 회돌이의 마지막에서 조건은 false가 되어야 한다. 만약 회돌이가 계속 진행되면, x와 y의 값을 볼 수 있을 것이다. 그리고 어쩌면 그 값들이 왜 갱신되고 있는지 정확하게 알 수 있을지도 모른다.
154 |
155 |
무한 재귀(Infinite Recursion)
156 |
157 | 무한 재귀때문에 프로그램은 대부분 잠시동안 실행되다가 "최대 재귀 깊이를 초과함(Maximum recursion depth exceeded)" 에러를 일으킬 것이다.
158 |
159 | 만약 한 함수 또는 메쏘드가 무한 재귀를 야기하고 있다고 의심된다면, 기저 케이스가 확실하게 있는지 제일 먼저 점검하라. 다른 말로 하면, 반드시 어떤 조건이 있어야만 그 함수 혹은 메쏘드가 재귀 호출을 하지 않고서도 복귀할 수 있을 것이다. 그렇지 않다면, 그 알고리즘을 재고하고 기저 케이스를 식별할 필요가 있다.
160 |
161 | 만약 기저 케이스는 있으나 프로그램이 거기에 도달하지 않는 것 같다면, print 서술문을 그 함수 혹은 메쏘드의 시작부분에 추가하여 매개변수들을 출력시켜라. 이제 프로그램을 실행시키면, 그 함수 혹은 메쏘드가 요청될 때마다 몇 줄의 출력을 볼 것이다, 그리고 여러분은 그 매개변수들을 볼 것이다. 매개변수들이 기저 케이스로 이동하지 않는다면, 왜 이동하지 않는지에 대하여 어떤 아이디어를 얻을 것이다.
162 |
163 |
실행의 흐름(Flow of Execution)
164 |
165 | 실행의 흐름이 어떻게 프로그램 전체를 통하여 움직이는지 확신하지 못한다면, print 서술문을 각 함수의 시작부분에 추가하여 다음과 같은 "함수 foo에 들어감"이라는 메시지를 출력하게 하라. 여기에서 foo는 그 함수의 이름이다.
166 |
167 | 이제 프로그램을 실행하면, 그 프로그램은 요청이 될 때마다 각 함수를 추적해 출력할 것이다.
168 |
169 |
프로그램을 실행하면 예외가 일어나요.
170 |
171 | 무언가 실행시간에 잘못되면 파이썬은 그 예외의 이름과 프로그램에서 문제가 발생한 줄 그리고 역추적을 담은 메시지를 출력한다.
172 |
173 | 역추적은 현재 실행되고 있는 함수를 식별한다. 그리고 그 함수를 요청하는 함수를, 그리고 또 그것을 요청하는 함수를, 등등을 식별한다. 다른 말로 하면, 역추적은 현재의 위치까지 오게한 함수 요청의 경로를 추적한다. 역추적에는 파일에서 각 호출이 일어난 곳의 줄 번호가 포함된다.
174 |
175 | 첫 번째 단계는 프로그램에서 에러가 일어난 위치를 조사하고 무엇이 일어났는지 이해할 수 있는지를 알아 보는 것이다. 다음은 가장 흔한 실행시간 에러들이다:
176 |
177 |
178 |
179 |
이름에러(NameError)
180 |
현재 환경에 존재하지 않는 변수를 사용하려고 시도하고 있다. 지역 변수들은 지역적이라는 것을 명심하라. 함수 안에 정의된 지역변수는 밖에서 참조할 수 없다.
181 |
182 |
유형에러(TypeError)
183 |
여러 원인이 가능하다:
184 |
185 |
186 |
187 | 값을 부적절하게 사용하려고 하고 있다. 예: 정수 말고 다른 어떤 것으로 문자열이나 리스트 또는 터플을 지표화하려고 하는 것.
188 |
189 | 형식화 문자열 안에 있는 항목들과 변환을 위해 넘겨진 항목들 사이에 불일치가 있다. 이것은 항목의 개수가 일치하지 않거나 유효하지 않은 변환이 요구될 때 일어날 수 있다.
190 |
191 | 함수 또는 메쏘드에 넘겨 주는 인자의 개수가 잘못되었다. 메쏘드라면 그 정의를 살펴 보고 첫 번째 매개변수가 self인지 점검하라. 그리고나서 그 메쏘드 요청을 살펴보라; 올바른 유형을 가진 객체에 메쏘드를 요청하고 있는지 그리고 다른 인자들을 정확하게 제공하고 있는지 확인하라.
192 |
193 |
194 |
키에러(KeyError)
195 |
사전이 가지고 있지 않은 키 값을 사용하여 그 사전의 요소에 접근하려 하고 있다.
196 |
197 |
속성에러(AttributeError)
198 |
존재하지 않는 속성 혹은 메쏘드에 접근하려 하고 있다.
199 |
200 |
지표에러(IndexError)
201 |
리스트나 문자열 또는 터플에 접근하기 위하여 사용하는 지표는 음수이거나 또는 그의 길이에서 1을 뺀 것보다 커야 한다. 그 에러가 일어난 장소 바로 앞에 print 서술문을 추가하여 지표의 값과 배열의 길이를 출력하라. 배열은 올바른 크기인가? 지표는 올바른 값인가?
202 |
203 |
204 |
205 |
print 서술문을 너무 많이 추가했더니 출력으로 넘쳐 흘러요.
206 |
207 | 디버깅을 하기 위해 print 서술문을 사용할 때의 문제중 하나는 프로그램이 끝날 때 출력에 파 묻힐 수 있다는 것이다. 두 가지의 처리 방법이 있다: 출력을 간결하게 하라; 또는 프로그램을 간결하게 하라.
208 |
209 | 출력을 간결하게 하려면, 별로 도움이 되지 않는 print 서술문들을 제거하거나 주석처리하면 된다. 또는 이해하기 쉽도록 그것들을 결합하거나 출력을 형식화 할 수 있다.
210 |
211 | 프로그램을 간결하게 하려면, 여러가지 방법이 있다. 첫 째, 문제를 최소화하여 프로그램을 작동시킨다. 예를 들어, 배열을 정렬하고 있다면, 작은(small) 배열을 정렬하라. 프로그램이 사용자로부터 입력을 받는다면, 입력은 문제를 야기하므로 최소한으로 입력하라.
212 |
213 | 두 번째, 프로그램을 깨끗하게 하라. 죽은 코드를 제거하고 프로그램을 재조직하여 되도록이면 쉽게 읽을 수 있도록 하라. 예를 들어, 문제가 프로그램에서 아주 깊숙히 내포된 부분에 있다고 의심된다면, 그 부분을 더 간결한 구조로 재작성해 보라. 거대한 함수가 의심되면, 그것을 더 작은 함수들로 쪼개어 따로따로 테스트 해보라.
214 |
215 | 가끔 최소한의 테스트 사례를 찾는 과정에서 버그를 발견하기도 한다. 한 프로그램이 어떤 상황에서는 작동하고 다른 상황에서는 그렇지 않다면, 그것을 보고 무엇이 진행되고 있는지 실마리를 찾을 수 있다.
216 |
217 | 비슷하게, 코드 조각을 약간만 재작성하면 미묘한 버그들을 찾아내는데 도움을 받을 수 있다. 변경을 하면서 프로그램에 영향을 미치지 않을 거라고 생각했지만 영향을 미치고 있다면 그것이 바로 실마리 정보가 될 수 있다.
218 |
219 |
220 |
의미구조 에러(Semantic errors)
221 |
222 | 어떤 면에서 의미구조 에러는 디버그하기가 가장 어려운 형태이다. 왜냐하면 컴파일러와 실행시간 시스템은 무엇이 잘못되었는지 어떠한 정보도 제공하지 않기 때문이다. 여러분이 아는 것은 오직 프로그램이 무엇을 했어야 하는지와 그리고 그 프로그램이 그 일을 하지 않는다는 것을 알 뿐이다.
223 |
224 | 첫 번째 단계는 프로그램 텍스트와 여러분이 보고 있는 행위 사이에 연결을 짓는 것이다. 프로그램이 실제로 무엇을 하고 있는지에 대한 가설이 필요하다. 연결을 어렵게 하는 것중의 하나는 컴퓨터가 너무 빠르다는 것이다.
225 |
226 | 종종 프로그램의 속도를 인간의 속도 정도로 늦출 수 있었으면 하고 바랄 것이다. 그리고 어떤 디버거로는 그렇게 할 수 있다. 그러나 배치가 잘 되도록 print 서술문을 삽입하는 데 걸리는 시간이 디버거를 설정하고 정지점을 삽입하고 제거하면서 에러가 발생한 곳까지 프로그램을 "진행시키는" 시간과 비교하여 짧은 경우가 많다.
227 |
228 |
프로그램이 작동하지 않아요.
229 |
230 |
스스로에게 이러한 질문을 물어 보아야 한다:
231 |
232 |
233 |
프로그램이 해야 하는 어떤 것이 있는가, 그런데 그런 일이 일어나지 않는 것 같은가? 그 함수를 수행하는 코드 부분을 찾아라 그리고 그래야만 한다고 생각할 때 그 함수가 실행되는지를 확인하라.
234 |
235 |
그래서는 안되는 일이 일어나는가? 프로그램에서 그 함수를 수행하는 코드를 찾아라 그리고 그래서는 안될 때 그 함수가 실행되는 지를 살펴보라.
236 |
237 |
예상하지 못한 효과를 산출하는 코드 조각이 있는가? 의문의 그 코드를 이해하고 있는지 확인하라. 특히 그 코드가 다른 파이썬 모듈에 있는 메쏘드나 함수를 요청하는 것과 연루되어 있는지를 확인하라. 요청하고 있는 함수들에 대한 문서를 읽어라. 간단한 테스트 사례를 작성하여 그 결과를 확인함으로써 그 함수들을 시험해 보라.
238 |
239 |
240 |
241 |
242 | 프로그래밍을 하기 위해서 프로그램이 작동하는 방법에 대한 정신적 모형을 가질 필요가 있다. 예상치 못한 행위를 하는 프로그램을 작성한다면, 상당부분의 문제는 그 프로그램에 있지 않다; 문제는 여러분의 정신적 모형에 있는 것이다.
243 |
244 |
245 | 여러분의 정신적 모형을 교정하는 가장 좋은 방법은 프로그램을 구성요소들로 쪼개어 (보통은 함수와 메쏘드이다) 각 구성요소를 독립적으로 테스트하는 것이다. 여러분의 정신 모형과 현실사이에 불일치를 발견하기만 하면, 문제를 해결할 수 있다.
246 |
247 |
248 | 물론, 구성요소들을 구축하고 테스트하면서 프로그램을 개발해야 할 것이다. 혹시 에러에 마주칠지라도 옳지 않다고 여겨지는 코드는 아주 적은 양의 새로운 코드만이 되어야 할 것이다.
249 |
250 |
거대하고 조잡한 표현식이 있는데 예상한대로 행동하지 않아요.
251 |
252 | 복잡한 표현식을 작성하는 것은 읽을 수 있기만 하다면 괜찮다. 그러나 그것은 디버그하기가 어려울 수 있다. 복잡한 표현식을 임시 변수에다 일련의 할당문들로 쪼개는 것이 때로는 좋은 생각이다.
316 | 먼저, 컴퓨터로부터 잠시동안 떨어져 있도록 하라. 컴퓨터는 뇌에 영향을 미치는 전파를 발산하여, 다음의 증상을 유발한다:
317 |
318 |
319 |
320 |
좌절과 그리고/또는 분노.
321 |
322 | 미신적인 믿음 ("컴퓨터는 나를 증오한다") 그리고 마법적인 생각 ("내가 모자를 거꾸로 쓰면 프로그램이 작동한다").
323 |
324 | 마음가는대로-걷기 프로그래밍 (모든 가능한 프로그램을 작성하고 올바를 일을 하는 프로그램 하나를 선택함으로써 프로그램하려는 시도).
325 |
326 |
327 | 이러한 증상들 때문에 고민하는 자신을 발견한다면 일어나 밖으로 나아가 산책을 하라. 마음이 가라 앉으면 프로그램에 대해 생각하라. 그 프로그램은 무엇을 하고 있는가? 어떤 원인이 그러한 행위를 일으킬 가능성이 있는가? 가장 마지막으로 프로그램이 제대로 작동했던 때는 언제인가. 그리고 그 다음에 여러분은 무엇을 했는가?
328 |
329 | 어떤 때는 버그를 발견하는 데 시간이 많이 걸린다. 가끔 컴퓨터에서 떨어져서 마음을 편하게 할 때 버그를 발견하기도 한다. 버그를 발견하기에 제일 좋은 장소는 열차안, 샤워할 때, 그리고 잠들기 바로 전 침대에 누워 있을 때이다.
330 |
331 |
아니오, 진짜로 도움이 필요해요.
332 |
333 | 그럴 것이다. 심지어는 특급 프로그래머들도 가끔씩 고민에 빠진다. 어떤 때는 너무 오랫동안 프로그램 작업을 하기 때문에 에러가 눈에 보이지 않을 정도이다. 눈에 상쾌한 바람을 한 번 쐬어 주는 것이 유일한 해결책이다.
334 |
335 | 다른 누군가를 부르기 전에, 먼저 이 부록에서 기술한 테크닉을 다 써 보았는지 확인하라. 프로그램은 가능한 한 간단해야 하며, 입력은 에러를 야기하므로 최소한으로 하여 작업해야 한다. 적절한 장소에 print 서술문을 배치해야 한다 (그리고 그 출력들은 이해가 되어야 한다). 문제를 간결하게 기술할 수 있을 만큼 충분히 이해해야 한다.
336 |
337 | 누군가를 불러서 도움을 요청한다면, 확실하게 그가 필요한 정보를 주어라:
338 |
339 |
340 | 에러 메시지가 있다면, 그것이 무엇이고 프로그램에서 어느 부분을 가르키고 있는가?
341 |
342 | 이 에러 메시지가 발생하기 전에 가장 마지막으로 한 일은 무엇인가? 가장 마지막에 작성한 코드는 무엇인가, 또는 실패한 새로운 테스트 사례는 무엇인가?
343 |
344 |
지금까지 어떠한 노력을 하였는가, 그리고 무엇을 배웠는가?
345 |
346 |
347 | 버그를 발견하면, 어떻게 했으면 그 버그를 더 빨리 발견할 수 있었을지 잠시 생각해 보라. 다음에 비슷한 어떤 것을 발견하면 그 버그를 더 빨리 발견할 수 있을 것이다.
348 |
349 | 기억하라, 목표는 프로그램을 그저 작동하게 하는 데에 있지 않다. 목표는 프로그램을 작동하게 하는 법을 배우는 것이다.
52 | 객체-지향 프로그래밍 언어 덕분에 프로그래머는 새로운 데이타 유형을 정의하여 내장 데이타 유형과 아주 비슷하게 행동하도록 만들 수 있다. Fraction이라는 클래스를 구축하여 내장 수치 형, 정수, 배정도 정수, 부동소수점수와 상당히 유사하게 작동시켜 보면서 이런 능력을 탐험해 보자.
53 |
54 | 분수는 유리수로도 알려져 있는데, 5/6처럼 정수의 비율로서 표현할 수 있다. 위의 숫자를 분자라고 하고 아래의 숫자를 분모라고 부른다.
55 |
56 | 먼저 Fraction 클래스를 정의해 보자. 이 클래스는 생성하고자 하는 분수에 대하여 정수 분모와 분자를 제공하는 구성자 메쏘드를 가진다:
>>> spam = Fraction(5,6)
91 | >>> print"The fraction is", spam
92 | The fraction is 5/6
93 |
94 |
95 |
96 |
97 |
98 |
분수 곱셈
99 |
100 | 분수에 대하여 정상적인 덧셈, 뺄셈, 곱셈, 그리고 나눗셈 연산을 적용할 수 있기를 원한다. 이렇게 하려면 Fraction 객체의 연산자들을 덮어쓰면 된다.
101 |
102 | 구현하기가 가장 쉽기 때문에 곱셈부터 시작해 보겠다. 먼저 두 분수를 곱하면 새로운 분수가 만들어지는데 이 분수의 분자는 원래 분자들을 곱한 것이고 분모는 원래 분모들을 곱한 것이다. __mul__은 * 연산자를 덮어쓰는 함수들을 위해 파이썬이 사용하는 이름이다:
124 | 그러나 다른 것 두가지를 고려해 볼 수 있다. 첫째, 정수에 분수를 곱하기를 원할 수 있다. 이것을 처리하는 한 방법은 그 정수를 그에 동등한 분수로 변환하는 것이다. type 함수를 사용하면 other이 정수인지 테스트해 볼 수 있고 정수라면 그것을 분수로 변환할 수 있다.
201 | 앞의 두 예제는 __add__를 요청한다; 마지막 예제는 __radd__를 요청한다.
202 |
203 |
204 |
유클리드 알고리즘
205 |
206 | 이전의 예제에서 5/6 + 5/6의 합을 계산하고 60/36을 얻었다. 그 값은 옳다. 그러나 해답을 표현하는 가장 좋은 방법은 아니다. 분수를 가장 단순한 항으로 약분(reduce)하려면, 분모와 분자를 최대 공약수(greatest common divisor (GCD))로 나눌 필요가 있는데, 여기에서 그것은 12이다. 그리하여 그 결과는 5/3이다.
207 |
208 | 일반적으로 새로운 Fraction 객체를 만들 때마다 그 객체의 분모와 분자를 GCD로 약분해야 한다. 분수가 이미 약분되어 있다면 GCD는 1이다.
209 |
210 | 유클리드는 m과 n 두 정수에 대한 GCD를 찾는 메쏘드 또는 알고리즘을 제시하였다:
211 |
212 |
m이 n으로 나누어 떨어진다면 n이 그 GCD이다. 그렇지 않으면 그 GCD는 m을 n으로 나눈 나머지와 n과의 GCD이다.
213 |
214 |
215 | 이러한 재귀적인 정의는 함수로 간결하게 표현할 수 있다:
216 |
217 |
218 |
defgcd (m, n):
219 | if m % n == 0:
220 | return n
221 | else:
222 | return gcd(n, m%n)
223 |
224 |
225 |
226 |
227 |
228 | 첫 번째 줄에서 나머지(modulus) 연산자를 사용하여 나눗셈이 가능한지 점검한다. 마지막 즐에서도 나머지(modulus) 연산자를 사용하여 나눗셈의 나머지를 계산한다.
229 |
230 |
231 | 지금까지 연산은 모두 그 결과로 분수(Fraction)를 새로 만들기 때문에 구성자를 수정하면 모든 결과를 약분할 수 있다:
232 |
233 |
234 |
class Fraction:
235 | def__init__(self, numerator, denominator=1):
236 | g = gcd (numerator, denominator)
237 | self.numerator = numerator / g
238 | self.denominator = denominator / g
239 |
240 |
241 |
242 |
243 |
244 | 이제 분수(Fraction)를 만들 때마다 가장 단순한 형태로 약분된다:
245 |
246 |
247 |
>>> Fraction(100,-36)
248 | -25/9
249 | >>>
250 |
251 |
252 |
253 | gcd 함수의 멋진 특징은 만약 분수가 음수라면 마이너스 표시가 항상 분자로 이동한다는 것이다.
254 |
255 |
256 |
분수를 비교하기
257 |
258 | Fraction 객체인 a와 b 두 개가 있고 a == b를 평가한다고 가정하자. 기본으로 구현된 ==는 얕은 동등성을 테스트한다, 그래서 a와 b가 같은 객체일 때만 참을 반환한다.
259 |
260 | 더욱 가능성 있는 예를 들자면 a와 b가 같은 값을 가지면 참을 반환하기를 원한다---다시 말하면, 깊은 동등성 테스트를 원한다고 하자.
261 |
262 | 비교를 하려면 분수에게 비교하는 법을 가르쳐 줄 필요가 있다. Card 객체에서 보았듯이 __cmp__ 메쏘드를 제공하면 비교 연산자를 덮어쓸 수 있다.
263 |
264 | 관례적으로 __cmp__ 메쏘드는 만약 self가 other보다 작다면 음의 정수를 반환해야 하고, 같다면 0을 돌려주어야 하고, self가 other보다 크다면 양의 정수를 반환해야 한다.
265 |
266 | 가장 간단하게 분수를 비교하는 방법은 양쪽으로-곱하는 것이다. 만약 a/b > c/d이라면, ad > bc이다. 이점을 염두에 두고 다음과 같이 __cmp__를 위한 코드를 살펴 보면:
280 | self가 other보다 크다면 diff는 양의 정수가 될 것이다. other가 더 크다면 diff는 음의 정수가 될 것이다. 같다면 diff는 0이다.
281 |
282 |
283 |
더 다듬어야 할 것
284 |
285 |
286 | 물론 아직 끝난 것이 아니다. 아직도 __sub__를 덮어 씀으로써 뺄셈을 구현하고 __div__를 덮어씀으로써 나눗셈을 구현할 필요가 있다.
287 |
288 | 그러한 연산들을 처리하기 위한 하나의 방법은 __neg__를 덮어씀으로써 보수(negation)를 구현하고 __invert__를 덮어씀으로써 역수(inversion)를 구현하는 것이다. 그러면 두 번째 피연산자를 보수로 만들고 더해서 뺄셈을 할 수 있고, 두 번째 피연산자를 역수로 만들고 곱해서 나눗셈을 할 수 있다.
289 |
290 | 마지막으로 __rsub__와 __rdiv__를 제공해야 한다. 불행하게도 덧셈과 나눗셈에 사용한 것과 같은 꼼수를 사용할 수 없다. 왜냐하면 뺄셈과 나눗셈은 위치를 교환할 수 없기 때문이다. 피연산자의 순서는 차이를 만든다.
291 |
292 | 사실 __neg__가 필요한 이유는 파이썬이 단항 부인을 처리할 수 있도록 하기 위한 것이다. 그렇지만 __rsub__와 __rdiv__는 __sub__와 __div__처럼 똑같이 단순하게 설정될 수 없다. 이러한 연산에 있어서, 피연산자들의 순서는 차이를 만들어 낸다.
293 |
294 | __pow__를 덮어쓰면 분수의 지수승을 계산할 수 있다. 그러나 그 구현은 약간 꼼수적이다. 지수가 정수가 아니라면 그 결과를 분수(Fraction)로 보여주지 못할 수도 있다. 예를 들어, Fraction(2) ** Fraction(1,2)는 2의 제곱근이다. 이것은 무리수이다 (다시 말해 분수로 표현될 수 없다). 그래서 지극히 일반적인 버전으로 __pow__를 작성하기는 쉽지 않다.
295 |
296 | Fraction 클래스에 대하여 또 다른 확장 하나를 생각해 볼 수도 있다. 지금까지는 분자와 분모가 정수라고 가정했다. 분자와 분모에 대하여 장정도 정수를 허용하고 싶을 수도 있다.
297 |
298 |
연습으로, Fraction 클래스를 완전히 구현하라. 그래서 뺄셈, 나눗셈, 지수, 그리고 장정도 정수를 분자와 분모로 처리할 수 있도록 하라.
52 | 여기서 어디로 가야 할까? 여러 방향으로 나아갈 수 있다. 파이썬 그 자체에 대한 지식을 확장하고 일반적인 컴퓨터 과학에 대한 지식 모두를 확장하는 방향으로 나아가야 한다.
53 |
54 | 이 책에서는 파이썬 확장의 세계를 의도적으로 언급하지 않았으며 더 근본적인 메시지에 초점을 맞추었다. 그러나 다음 예들은 어떻게 또 파이썬이 이용될 수 있는지를 보여주는 사례들이다.
55 |
56 |
57 |
58 |
59 | 그래픽과 구이(GUI) 프로그래밍으로 프로그램은 창 환경을 통하여 사용자와 대화할 수 있고 그래픽을 제공할 수 있다. 여러 방식의 구현이 현재 존재한다. 가장 오래된 패키지는 Tkinter로서 존 아우스터호우트(Jon Ousterhout)의 TCL/TK 스크립트 언어에 기초하고 있으며 파이썬에 함께 묶여 배포된다. 또 다른 인기있는 플랫폼은 wxPython으로서 본질적으로 wxWindows를 둘러 싼 파이썬 포장자(wrapper)이다. wxWindows는 C++ 패키지로 이번에는 윈도우와 유닉스(리눅스) 고유의 인터페이스를 이용하여 창을 구현한다. wxPython 아래의 창과 콘트롤은 Tkinter의 시각 느낌(look and feel)보다 더욱 고유한 시각 느낌을 가지는 경향이 있으며 프로그램하기에 약간 더 쉽다. 모든 종류의 구이 프로그램은 사건 지향 프로그래밍에 관련되는데, 거기에서는 프로그램이 아니라 사람이 실행의 흐름을 결정한다. 이 때문에 프로그램의 전체 구조를 다시 생각해 보아야 한다.
60 |
61 | 파이썬의 힘은 웹 프로그래밍을 통하여 인터넷에 미친다. 웹 클라이언트 프로그램을 구축하여, 예를 들어 멀리 떨어진 웹 페이지를 디스크에 있는 파일을 읽듯이 아주 쉽게 열고 읽을 수 있다. ftp를 통하여 원격 파일에 접근하도록 하여주는 파이썬 모듈이 있으며, 전자우편을 주고 받도록 하여주는 모듈도 있다. 파이썬은 웹 서버 프로그램에도 광범위하게 이용되어 사용자가 채워 넣고 제출하는 입력 폼을 처리할 수 있다.
62 |
63 | 데이타베이스는 미리정의된 스키마에 데이타가 저장되는 슈퍼 파일과 약간 비슷하며 그리고 데이타 항목 사이의 관계를 이용하여 그 데이타에 쉽게 다양한 방법으로 접근할 수 있다. 파이썬에는 사용자가 다양한 데이타베이스 엔진에 연결하도록 하여 주는 여러 모듈이 오픈 소스와 상업적 형태로 존재한다.
64 |
65 |
66 | 쓰레드 프로그래밍을 이용하면 하나의 프로그램 안에서 다수의 쓰레드를 실행할 수 있다. 웹 브라우저를 이용하여 한 페이지의 처음으로 스크롤하는 동안 브라우저는 나머지 내용들을 계속하여 적재하는 것을 경험해 보았다면, 여러분은 쓰레드가 무엇을 하는 것인지 감을 잡고 있는 셈이다.
67 |
68 | 속도가 우선이라면 파이썬 확장을 컴파일 언어, 특히 C 과 C++로 다시 작성하면 된다. 실제로 파이썬 라이브러리에 있는 많은 모듈들의 토대는 다른 사람들에 의해서 작성된 그러한 확장으로 형성된다. 함수와 데이타를 링크하는 메카니즘은 약간 복잡하다. SWIG(Simplified Wrapper and Interface Generator)은 그런 처리과정을 매우 단순하게 만들어 주는 도구중 하나이다.
69 |
70 |
71 |
72 |
73 |
파이썬에 관련된 웹 사이트와 책
74 |
75 | 다음은 필자들이 파이썬 언어에 대하여 더 읽기를 권장하는 재료들이다.
76 |
77 |
78 |
79 | 파이썬의 홈 페이지 www.python.org는 모든 파이썬 관련 재료의 탐색을 시작하는 장소이다. 거기에 가면 내려받기, 도움말, 문서, 다른 사이트로 가는 링크가 있으며 여러분이 가입해 활동할 동호회(Special Interest Group) 메일링 리스트로 가는 링크가 있을 것이다.
80 |
81 | 필자의 홈 페이지www.ibiblio.org/obp는 이 책을 온라인으로 가지고 있을 뿐만 아니라 이 책과 유사한 알렌 다우니(Allen Downey)가 쓴 자바와 C++에 대한 온라인 책도 가지고 있다. 게다가 네 가지 프로젝트가 진행중인데, 토니 누팔트(Tony R. Kuphaldt)의 전자 회로 수업(Lessons in Electric Circuits)과, 고등 학교 선생님들이 집필하고 편집한 파고 들어가기...(Getting down with ...)라는 프로젝트가 있는데, 이것은 컴퓨터 과학이라는 주제에 대한 한 모둠의 자습서들이다. 그리고 크리스 메이어스(Chris Meyers)의 재미를 위한 파이썬(Python for Fun)에는 파이썬으로 하는 사례 연구가 있다. 마이클 스털츠(Michael Stultz)의 리눅스 요리책(The Linux Cookbook)에는 300 페이지에 걸쳐서 팁과 테크닉이 있다.
82 |
83 | 마지막으로 www.google.com에서 검색하려면 다음의 탐색 문자열 "python -snake -monty"을 사용해 보자. 그러면 약 750,000 개의 적중을 얻을 것이다.
84 |
85 | 웨슬리 춘(Wesley Chun)이 쓴 핵심 파이썬 프로그래밍(Core Python Programming)은 약 750 페이지의 방대한 책이다. 그 책의 전반부는 기본적인 파이썬 언어의 사양을 다룬다. 후반부는 위에 언급한 많은 주제들을 포함하여 더욱 진보된 주제로 쉽게 내딛을 수 있도록 개론을 제공한다.
86 |
87 | 반면에 데이비드 비즐리(David M. Beazley)가 쓴 파이썬 필수 참조서(Python Essential Reference)는 작은 책이다. 그러나 파이썬 언어 그 자체와 표준 라이브러리에 있는 모듈들에 대한 정보로 빽빽히 차 있다. 또한 인덱스가 아주 잘 되어 있다.
88 |
89 | 마크 루츠(Mark Lutz)의 파이썬 포켓 참조서(Python Pocket Reference)는 주머니에 쏙 들어가는 책이다. 파이썬 필수 참조서만큼 광범위하지는 않음에도 불구하고 아주 흔하게 사용되는 함수와 모듈을 참조할 수 있어서 유익하다. 마크 루츠는 또한 프로그래밍 파이썬(Programming Python)의 저자인데, 이 책은 파이썬에 관한 초기의 (그리고 가장 방대한) 책중의 하나로 초보 프로그래머를 대상으로 하지 않는다. 이후에 나온 그의 책인 파이썬을 배우기(Learning Python)는 더 작아지고 더 보기가 쉬워졌다.
90 |
91 | 마크 해몬드(Mark Hammond)와 앤디 로빈슨(Andy Robinson)이 쓴 윈 32에서의 파이썬 프로그래밍(Python Programming on Win32)은 파이썬을 최대한 이용하여 윈도우 어플리케이션을 개발할 사람들에게는 "필수"이다. 다른 어떤 것보다 이 책은 파이썬과 COM의 통합을 다루고 있으며, wxPython으로 작은 어플리케이션을 구축하고, 심지어는 파이썬을 사용하여 워드와 엑셀같은 윈도우 어플리케이션을 스크립트하는 법을 보여 준다.
92 |
93 |
94 |
95 |
96 |
권장하는 일반 컴퓨터 과학 도서
97 |
98 | 더 읽어야할 재료로 다음에 제시하는 것들은 필자들이 즐겨 보는 책들을 상당부분 포함하고 있다. 제시된 책들은 좋은 프로그래밍 습관과 컴퓨터 과학 일반을 다루고 있다.
99 |
100 |
101 | 커니건과 파이크(Kernighan과 Pike)가 쓴 프로그래밍 연습(Practice of Programming)은 알고리즘과 데이타 구조를 디자인하고 코딩하는 것뿐만 아니라 프로그램의 수행능력을 디버그하고 테스트하며 그리고 증진시키는 방법을 다룬다. 예제들은 여러 언어로 되어 있는데 대단히 유명한 C++와 자바로 되어 있느나, 불행하게도 파이썬으로 된 예제는 없다.
102 |
103 | 알 버뮬렌(Al Vermeulen)이 편집한 자바 스타일의 요소들(Elements of Java Style)은 이름짓기 관례와 주석 그리고 심지어 (파이썬에서는 큰 논쟁거리가 되지 않지만) 공백과 좋은 들여쓰기와 같은 사용법에 대하여 훌륭한 프로그래밍을 더 자세하게 논의한다. 이 책은 언명(assertions)을 사용하여 전조건(preconditions)과 후조건(postconditions)을 테스트함으로써 에러를 나포하는 계약(contract) 프로그래밍을 다루고 있으며 쓰레드와 조화를 이룬 프로그래밍 방법을 다룬다.
104 |
105 |
106 | 존 벤틀리(Jon Bentley)가 쓴 보석같은 프로그래밍(Programming Pearls)은 고전이다. 이 책은 원래 저자의 Communications of the ACM 컬럼에서 나타나는 사례 연구들로 구성되어 있다. 그 연구들은 프로그래밍에서의 교환관계를 다룬다. 그리고 프로그램에 대하여 제일 처음 떠오르는 아이디어로 프로그램을 실행하는 것이 어떤 때는 왜 특별히 나쁜 아이디어가 되는지 그 이유를 다룬다. 이 책은 위의 것(1986) 보다는 약간 오래되었다. 그래서 예제들도 상응하여 오래된 언어로 되어 있다. 풀어야 할 많은 문제들이 있으며, 어떤 문제는 해법이 주어지고 어떤 것은 힌트가 주어진다. 이 책은 대단히 인기를 끌었으며 이후에 제 2 판이 나왔다.
107 |
108 | 듀니(A.K Dewdney)가 쓴 새로운 튜링 옴니버스(The New Turing Omnibus)는 컴퓨터 과학에 대한 66 가지의 주제를 병렬 컴퓨팅에서부터 컴퓨터 바이러스까지, 삼차원 영상 진료에서부터 일반적인 알고리즘까지, 아울러서 유연하게 소개한다. 모든 주제들은 간결하고 재미 있다. 듀니(A.K Dewdney)가 이전에 쓴 책 우주의 안락의자(The Armchair Universe)는 과학적인 미국인(Scientific American)에 있는 그의 컬럼 컴퓨터 여가(Computer Recreations)의 모음집이다. 두 책 모두 프로젝트 시작을 위한 아이디어의 근원으로 충만하다.
109 |
110 | 미첼 레스닉(Mitchel Resnick)의 거북이와 흰개미 그리고 교통 체증(Turtles, Termites and Traffic Jams)은 분산화의 힘에 대한 것으로서, 무수한 행위자들의 협력적인 단순 행위로부터 어떻게 복잡한 행위가 일어날 수 있는지를 다루고 있다.
111 |
112 | 이 책에서는 스타로고(StarLogo)라는 언어를 소개하는데, 이 언어를 사용하여 사용자는 간단한 프로그램을 작성할 수 있으며 그 프로그램 다음에 모든 행위자들이 따른다.
113 |
114 |
115 | 프로그램을 실행하면 때로는 대단히 반직관적인 복잡한 군집 행동을 보여준다. 책에 있는 많은 프로그램은 중학교와 고등학교 학생들이 개발하였다. 비슷한 프로그램들을 간단한 그래픽과 쓰레드를 사용하여 파이썬으로 작성할 수 있을 것이다.
116 |
117 | 더글라스 호프스타터(Douglas Hofstadter)가 쓴 고델과 에셔 그리고 바하(Godel, Escher and Bach)가 있다. 간단히 이야기 해서, 만약 여러분이 재귀에서 마법을 발견하였다면 이 베스트셀러에서도 역시 신비한 마법을 발견할 것이다. 호프스타터의 주제중 하나는 "이상한 회돌이(strange loops)"인데, 거기에서 패턴은 자신을 또 다시 만족시킬 때까지 진화하고 승화된다. 호프스타터는 그러한 "이상한 회돌이"가 죽은 것과 산것을 구별하는 중요한 부분이라고 주장한다. 그는 그러한 패턴을 바하(Bach)의 음악과 에셔(Escher)의 그림 그리고 고델(Godels)의 미완성 공리에서 보여 준다. 책을 읽다 보면 형식 시스템을 방문하고 재귀와 101 가지의 다양한 주제들을 방문한다.
103 | 이 함수는 Time 객체 하나를 새로 만들고 그의 속성들을 초기화하며 그리고 새로 생성된 객체에 대한 참조점을 돌려줍니다. 이런 함수를 일컬어 순수한 함수(pure function)라고 부르는데 왜냐하면 매개변수로 건네지는 어떠한 객체도 변경하지 않으며 값을 화면에 표시한다든가 또는 사용자 입력을 얻는다든가 하는 다른 작용을 전혀 하지 않기 때문입니다.
104 |
105 | 다음은 이 함수를 사용하는 법을 보여줍니다. Time 객체 두 개를 만들겠습니다: 하나는 currentTime으로 현재 시간을 담고 있습니다; 그리고 다른 하나는 breadTime으로 제빵사가 빵을 굽는데 걸린 시간을 담고 있습니다. 그리고 나서 addTime을 사용하여 언제 빵이 완성될지를 알아낼 것입니다. 아직 printTime 함수를 작성하지 못했다면, 다음 코드를 시도하기 전에 먼저 섹션 14.2를 살펴 보세요:
145 | 이 함수는 옳기는 하지만 코드가 커지기 시작합니다. 나중에 더 짧은 코드를 만들어 내는 대안을 제시하겠습니다
146 |
147 |
148 |
13.3 변경자(Modifiers)
149 |
150 |
151 | 가끔은 함수가 매개변수로 받아들이는 객체들 중의 하나 이상을 변경하는 것이 유용할 때가 있습니다. 보통, 호출자는 건네주는 객체들에 대한 참조점을 유지하고 있습니다. 그래서 그 함수가 어떤 변경을 해도 호출자가 모두 볼 수 있습니다. 이런식으로 작동하는 함수를 변경자(modifiers)라고 부릅니다..
152 |
153 | increment는 초를 주어진 개수만큼 Time 객체에 더하기 때문에 아주 자연스럽게 변경자로 작성될 수 있을 것입니다. 함수를 대충 작성해 보면 다음과 같이 보입니다:
170 | 첫 번째 줄은 기본 연산을 수행합니다; 나머지는 이전에 본 특수한 경우들을 다루고 있습니다.
171 |
172 |
173 | 다음 함수는 올바른가요? 만약 매개변수 secs가 60보다 훨씬 더 크다면 무슨 일이 일어납니까? 그런 경우에는 한 번의 자리이동만으로는 충분하지 않습니다; seconds가 60보다 작아질 때까지 계속해서 자리이동을 해야 합니다. 한가지 해결책은 if 서술문을 while 서술문으로 대치하는 것입니다:
두 번째 연습으로, increment를 순수한 함수로 재작성해 보세요. 그리고 두 버전 모두에 대해 함수 호출을 작성해 보세요.
192 |
193 |
194 |
13.4 어느 것이 더 좋은가?
195 |
196 |
197 | 변경자로 할 수 있는 모든 것은 순수한 함수로도 역시 모두 할 수 있습니다. 사실, 어떤 프로그래밍 언어들은 오로지 순수한 함수만을 허용합니다. 순수한 함수를 사용하는 프로그램이 변경자를 사용하는 프로그램보다 더 빠르게 개발되고 에러를 덜 야기한다는 증거들이 있습니다. 그럼에도 불구하고, 때로는 변경자가 편리하며 어떤 경우에는 함수적 프로그램이 비효율적입니다.
198 |
199 |
200 | 일반적으로, 그럴만한 이유가 있을 때마다 되도록이면 순수한 함수를 작성하기를 권장하며 변경자는 어쩔 수 없는 이점이 있을 때만 고려해 보시기를 권고합니다. 이러한 접근법을 함수적 프로그래밍 스타일이라고 부를 수도 있습니다.
201 |
202 |
203 |
13.5 원형 개발 대 계획
204 |
205 |
206 | 이 장에서는 원형 개발(prototype development)이라고 부르는 프로그램 개발에 대한 접근법을 예시해 보여 주었습니다. 각각의 경우에 기본적인 계산을 수행하는 대략적인 초안(또는 원형(prototype))을 작성해서 그 원형을 몇몇 사례에 대하여 테스트 해보고 결점들이 발견되면 교정하였습니다.
207 |
208 |
209 | 이런 접근법이 효과적일 수 있음에도 불구하고 불필요하게 복잡한 코드를 만들게 될 가능성이 있습니다---왜냐하면 특수한 경우들을 많이 다루기 때문입니다---그리고 신뢰할 수 없는 코드가 될 가능성이 있습니다---왜냐하면 모든 에러를 발견했는지 알 수 없기 때문입니다.
210 |
211 |
212 | 또 다른 대안은 계획된 개발(planned development)이라고 하는데 문제를 더 높은-수준에서 통찰할 수 있기 때문에 훨씬 더 쉽게 프로그래밍을 할수 있습니다. 이 경우에는 Time 객체가 실제로는 60진법의 3-자리 수라는 것을 통찰할 수 있습니다! second 구성요소는 "1의 자리"이고 minute 구성요소는 "60의 자리"이며 그리고 hour 구성요소는 "3600의 자리"입니다.
213 |
214 |
215 | addTime과 increment를 작성할 때, 60진법을 사용하여 효과적으로 덧셈을 하고 있었습니다. 60진법을 사용했던 이유는 한 자리에서 다른 자리로 올림을 해야 했기 때문입니다.
216 |
217 |
218 | 이렇게 관찰해 보면 전체 문제에 대해서 또 다른 접근법을 생각해 볼 수 있습니다---Time 객체를 한 자리 수로 변환할 수 있으며 컴퓨터가 숫자들을 수리적으로 처리하는 법을 알고 있다는 사실을 이용할 수 있습니다. 다음 함수는Time 객체를 정수로 변환합니다:
252 | 이 버전이 원래 버전보다 훨씬 더 짧습니다. 그리고 (보통때 처럼 호출되는 함수들이 옳다는 가정하에) 이 버전이 옳다는 것을 훨씬 더 쉽게 보여줄 수 있습니다.
253 |
254 |
연습으로, 같은 방식으로 increment 함수를 재작성해 보세요.
255 |
256 |
257 |
13.6 일반화
258 |
259 |
260 | 어떤 면에서 60진법을 10진법으로 그리고 그 반대로 변환하는 것이 단순히 시간을 다루는 것보다 더 어렵습니다. 진법변환이 더 추상적이며; 시간을 다루는데는 직관이 더 좋기 때문입니다.
261 |
262 |
263 | 그러나 시간을 60진수로 다룰 통찰력이 있고 변환 함수(convertToSeconds와 makeTime)를 작성하는데 투자한다면, 우리가 얻는 프로그램은 더 짧고 읽고 디버그하기에 더 쉽고, 더욱 신뢰할 만할 것입니다.
264 |
265 |
266 | 또 나중에 특징들을 새로 추가하기도 더 쉽습니다. 예를 들어, 두 개의 Time 사이를 빼서 그들 사이의 기간을 계산한다고 상상해 보세요. 초보적인 접근법은 빌림이 있는 뺄셈을 구현하는 것이 될 것입니다. 변환 함수들을 사용하게 되면 더 쉽게 교정될 수 있으며 그리고 교정에 성공할 가능성이 더욱 높을 것입니다.
267 |
268 |
269 | 묘하게도 어떤 때는 문제를 더 어렵게(즉 더욱 일반적으로) 만들면 더 쉽게 해결할 수 있게 됩니다. (왜냐하면 특수한 경우들이 더 적으며 에러의 가능성도 더 적기 때문입니다).
270 |
271 |
272 |
13.7 알고리즘
273 |
274 |
275 | 문제 하나에 대한 구체적인 해결책과는 대조적으로, 한 부류의 문제들에 대하여 일반적인 해결책을 작성한다면 알고리즘(algorithm)을 작성한 것이 됩니다. 이전에 이 단어를 언급한 바 있지만 신중하게 정의하지는 않았습니다. 알고리즘(algorithm)을 정의하기는 쉽지 않습니다. 그래서 여러 접근법을 시도해 보겠습니다.
276 |
277 |
먼저, 알고리즘이 아닌 것을 생각해 봅시다. 한-자리 수 곱셈을 배울 때 아마도 구구단을 암기했을 것입니다. 요컨데, 100가지 구체적인 해결책을 암기했던 것입니다. 그런 종류의 지식은 알고리즘적이 아닙니다.
278 |
279 |
280 | 그러나 만약 여러분이 "게으르다면(lazy)", 약간의 꼼수를 배워서 속일 수 있었을 것입니다. 예를 들어, n과 9의 곱을 찾으려면, n-1을 첫 번째 자리로 그리고 10-n을 두 번째 자리로 쓸 수 있습니다. 이런 꼼수는 9와 한 자리수 곱셈을 해결하는 일반적인 해결책입니다. 그것이 바로 알고리즘입니다!
281 |
282 |
283 | 비슷하게, 덧셈에서 올림과 뺄셈에서 빌림 그리고 배정도 나눗셈에 대하여 배운 테크닉들은 모두 알고리즘입니다. 알고리즘의 특징중 하나는 전혀 지능을 동반할 필요가 없다는 것입니다. 알고리즘은 각 단계가 간단한 규칙의 모둠에 의거하여 마지막까지 이어지는 기계적인 처리과정입니다.
284 |
285 |
286 | 알고리즘을 실행하는 법을 배우면서 그 많은 시간을 학교에서 낭비하는 것은 안타까운 일입니다. 알고리즘을 실행하는 법은 문자 그대로 아무런 지능도 요구하지 않습니다.
287 |
288 |
289 | 반면에, 알고리즘을 디자인하는 과정은 재미있고 지적인 도전이며 그리고 프로그래밍이라고 부르는 것의 핵심부분입니다.
290 |
291 |
292 | 사람들이 자연스럽게, 아무 어려움 없이 또는 의식적인 생각을 하지 않고서 하는 것들은 알고리즘적으로 표현하기가 정말 어렵습니다. 자연어에 대한 이해가 좋은 예입니다. 누구나 자연스럽게 말합니다. 그러나 지금까지 아무도 어떻게 자연스럽게 말할 수 있는지 적어도 알고리즘의 형태로는 설명할 수 없었습니다.
293 |
294 |
295 |
13.8 용어 해설
296 |
297 |
298 |
299 |
순수한 함수(pure function)
300 |
매개변수로 받아들이는 객체들을 전혀 변경하지 않는 함수. 아주 순수한 함수는 유익(fruitful)하다.
301 |
302 |
변경자(modifier)
303 |
매개변수로 받아들이는 객체들을 하나 이상 변경하는 함수. 지극한 변경자는 쓸모가 없다(void).
304 |
305 |
기능적 프로그래밍 스타일(functional programming style)
306 |
프로그램 디자인 스타일의 일종으로 이런 스타일에서는 상당수가 순수한 함수들이다.
307 |
308 |
원형 개발(prototype development)
309 |
원형에서 시작하여 점차적으로 그 원형을 테스트하고 개선시켜 나가면서 프로그램을 개발하는 방법.
310 |
311 |
계획된 개발(planned development)
312 |
점증적 개발 또는 원형 개발보다는 더 계획적이며 문제에 대한 고-수준의 통찰이 관련된 프로그램 개발 방법.
313 |
314 |
알고리즘(algorithm)
315 |
한 부류의 문제들을 기계적이고 비지능적인 처리과정으로 해결하기 위한 한 모둠의 지령어.
316 |
317 |
318 |
319 |
320 |
연습문제
321 |
322 |
323 | print_time 함수를 작성하라. 이 함수는 Time 객체를 인자로 받아 hours:minutes:seconds의 형태로 인쇄한다.
324 |
325 |
326 |
327 | 불리언 함수 after를 작성하라. 이 함수는 두 개의 Time 객체 t1과 t2를 인자로 받아 시간적으로 t1이 t2 다음에 오면 True를 돌려주고 그렇지 않으면 False를 돌려준다.
328 |
329 |
330 |
331 | increment 함수가 회돌이를 하나도 포함하지 않도록 재작성하라.
332 |
333 |
334 |
335 | 이제 increment를 순수한 함수로 재작성하고, 두 버전 모두에 대하여 함수 호출을 작성하라.
336 |
56 | 지금까지 살펴 본 데이타 형들은 그 데이타 형을 어떻게 구현될 지 완전하게 지정한다는 의미에서 모두 구체적인 것입니다. 예를 들어 Card 클래스는 두 개의 정수를 사용하여 하나의 카드를 표현합니다. 그 때 연구한 바와 같이 그것만이 카드를 표현하는 유일한 방법은 아닙니다; 다른 방식의 구현이 많이 있습니다.
57 |
58 |
추상적인 데이타 유형(abstract data type (ADT))는 한 모둠의 연산(즉 메쏘드)과 그 연산의 의미구조(무엇을 할지)는 지정하지만 그 구현은 지정하지 않습니다. 이런 이유로 추상적이 됩니다.
59 |
60 |
왜 ADT는 유용한가?
61 |
62 |
63 |
연산이 어떻게 수행되는지에 대하여 생각할 필요없이 필요한 연산을 동시에 표기할 수 있다면, 알고리즘을 지정하는 작업이 간단해집니다.
64 |
65 |
ADT를 구현하는 방법에는 보통 여러가지가 있으므로, 가능한 모든 구현에 사용할 수 있도록 알고리즘을 작성하는 것이 유용할 것입니다.
66 |
67 |
잘-알려진 ADT들은 이 장에서의 ADT와 같이 보통 표준 라이브러리에 구현되어 있으므로 한번 작성되기만 하면 많은 프로그래머들이 사용할 수 있습니다.
68 |
69 |
ADT에 대한 연산들은 보통 고-수준 언어로 알고리즘을 논의하고 지정합니다.
70 |
71 |
72 |
73 |
74 | ADT에 대하여 논의할 때 종종 클라이언트(client)와 프로바이더(provider)로 구분합니다. 클라이언트는 ADT를 사용하는 코드이고 프로바이더는 ADT를 구현하는 코드입니다.
75 |
76 |
77 |
78 |
79 |
18.2 스택 ADT
80 |
81 | 이 장에서는 일반적인 ADT 하나, 즉 stack을 살펴 보겠습니다. 스택은 집단입니다. 다시 말해 여러 요소들을 포함하고 있는 데이타 구조를 뜻합니다. 지금까지 본 다른 집단으로는 사전과 리스트가 있습니다.
82 |
83 |
84 | ADT는 이 자료에 대해 수행될 수 있는 연산들로 정의되는데, 이것을 접근방식(interface)이라고 부릅니다. 스택에 대한 접근방식은 다음과 같은 연산으로 구성됩니다:
85 |
86 |
87 |
88 |
__init__
89 |
빈 리스트 하나를 새롭게 초기화한다.
90 |
91 |
push
92 |
스택에 항목 하나를 새롭게 추가한다.
93 |
94 |
pop
95 |
스택으로부터 항목을 제거하고 반환한다. 반환되는 항목은 항상 마지막으로 추가된 항목이다.
96 |
97 |
isEmpty
98 |
스택이 비었는지 점검한다.
99 |
100 |
101 |
102 |
103 | 종종 스택은 "후입 선출", 즉 LIFO 데이타 구조라고 불리우는데, 가장 마지막으로 추가된 항목이 제일 먼저 제거되기 때문입니다.
104 |
105 |
106 |
18.3 파이썬의 리스트로 스택을 구현하기
107 |
108 | 파이썬이 제공하는 내장 리스트는 스택을 정의하는 연산과 유사합니다. 리스트의 접근방식은 정확하게 예상한대로는 아닙니다. 그러나 스택 ADT로부터 내장 연산으로 번역하는 코드를 작성할 수 있습니다.
109 |
110 |
111 | 이런 코드를 스택 ADT의 구현(implementation)이라고 부릅니다. 일반적으로, 구현이란 접근방식에 대한 구문적 요구조건과 의미구조적 요구조건을 만족하는 메쏘드들의 모둠입니다.
Stack 객체는 items라는 이름의 속성을 가지는데 이것은 스택에 있는 항목들의 리스트입니다. 초기화 메쏘드는 items를 빈 리스트로 설정합니다.
134 |
135 | 스택에 새로운 항목 하나를 올려 놓기 위해 push는 항목을 items에 추가합니다. 스택에서 항목 하나를 꺼내기 위해 pop은 똑 같은 이름의 list 메쏘드를 사용하여 리스트에서 마지막 항목을 제거해서 반환합니다.
136 |
137 |
138 | 마지막으로 스택이 비었는지 점검하기 위해 isEmpty는 items를 빈 리스트와 비교합니다.
139 |
140 | 이와 같이 간단한 구현에서는 메쏘드가 기존의 메쏘드를 단순히 호출하는 것으로 구성되어 있으므로, 이런 구현을 겉껍질(veneer)이라고 부릅니다. 실제 삶에서 겉껍질(veneer)은 좋은 품질의 나무로 된 얇은 코팅막으로서 가구-만들기에 사용되어 밑에 있는 조악한 품질의 나무를 감추어 줍니다. 컴퓨터 과학자는 이 은유법을 사용하여 작은 조각 코드를 기술합니다. 이것은 구현의 세부사항을 감추고 더 간단하고 더욱 표준적인 접근방식을 제공합니다.
141 |
142 |
143 |
18.4 눌러넣기(Pushing)와 튀겨꺼내기(popping)
144 |
145 | 스택은 총괄 데이타 구조(generic data structure)입니다. 이는 어떤 종류의 항목도 거기에 추가할 수 있다는 것을 의미합니다. 다음 예제는 정수 두 개와 문자열 한 개를 스택에 눌러 넣습니다:
157 | isEmpty와 pop을 사용하여 스택에 있는 모든 항목들을 제거하고 인쇄합니다:
158 |
159 |
160 |
while not s.isEmpty() :
161 | print s.pop(),
162 |
163 |
164 |
165 | 출력 결과는 + 45 54입니다. 다른 말로 하면, 오로지 스택을 이용하여 항목들을 거꾸로 인쇄합니다! 허용이 안되는 것은 아니지만, 그것은 리스트를 출력하기 위한 표준적인 방식이 아닙니다. 그러나 스택을 사용하면 놀랍도록 쉽게 처리할 수 있습니다.
166 |
167 | 이 코드 조각을 섹션 17.4에 있는 printBackward의 구현과 비교해 보아야 합니다. 여기에서의 스택 알고리즘과 재귀적인 버전의 printBackward 사이에는 자연스럽게 비교 관계가 있습니다. 그 차이는 printBackward가 리스트를 순회하면서 실행시간 스택을 사용하여 노드들을 추적 유지하고, 재귀로부터 복귀하면서 그 노드들을 인쇄한다는 것입니다. 스택 알고리즘도 그와 똑 같은 일을 합니다. 다만 실행시간 스택 대신에 Stack 객체를 사용한다는 점만 빼고 말입니다.
168 |
169 |
170 |
18.5 스택을 사용하여 후위식(postfix)을 평가하기
171 |
172 | 대부분의 프로그래밍 언어에서 수학적 표현식은 두 피연산자 사이에 있는 연산자로 작성됩니다, 1+2과 같이 말입니다. 이런 형식을 중위식(infix)이라고 부릅니다. 어떤 계산기는 후위식(postfix)이라는 다른 방식을 사용합니다. 후위식에서 연산자는 피연산자 뒤에 있습니다. 1 2 +와 같이 말입니다.
173 |
174 | 후위식이 종종 유용한 이유는 스택을 사용하면 자연스럽게 후위 표현식을 평가할 수 있기 때문입니다:
175 |
176 |
177 |
178 |
표현식의 처음에서 시작하여, 한 번에 한 항(연산자 또는 피연산자)를 얻는다.
179 |
180 |
181 |
182 |
만약 그 항이 피연산자라면, 그것을 스택에 눌러넣는다.
183 |
184 |
만약 그 항이 연산자라면, 두 개의 피연산자를 스택에서 튀겨 꺼낸다. 그것들에 대하여 연산을 수행한다. 그리고 그 결과를 다시 스택에 눌러넣는다.
185 |
186 |
187 |
188 |
표현식의 끝에 도달하면 스택에는 정확하게 하나의 피연산자만 남아 있을 것이다. 그 피연산자가 결과이다.
189 |
190 |
191 |
192 |
연습으로, 이 알고리즘을 1 2 + 3 * 표현식에 적용해 보세요.
193 |
194 |
195 | 이 예제는 후위식의 장점중 하나를 보여줍니다---연산의 순서를 제어하기 위하여 괄호를 사용할 필요가 전혀 없습니다. 중위식으로 같은 결과를 얻으려면 (1 + 2) * 3과 같이 작성해야 할 것입니다.
196 |
197 |
연습으로, 1 + 2 * 3과 동등한 후위 표현식을 작성해 보세요.
198 |
199 |
200 |
18.6 해석(Parsing)
201 |
202 |
203 | 이전의 알고리즘을 구현하려면 문자열을 순회하여 그것을 연산자와 피연산자로 쪼갤 수 있어야 합니다. 이 과정은 해석(parsing)의 한 예 입니다. 그리고 그 결과들은--- 분해된 문자열의 덩어리들 각각을 ---토큰(tokens)이라고 부릅니다. 제 1 장에서 이러한 단어들을 본 기억이 나실 것입니다.
204 |
205 | 파이썬은 split 메쏘드를 string 모듈과 re (정규 표현식(regular expression)) 모듈 모두에 제공합니다. 다음 함수 string.split은 한 개의 문자를 구분자(delimiter)로 사용하여 문자열을 리스트로 분리합니다. 예를 들어:
206 |
207 |
208 |
>>> import string
209 | >>> string.split("Now is the time"," ")
210 | ['Now', 'is', 'the', 'time']
211 |
212 |
213 |
214 |
215 |
216 | 이 경우에 구분자는 공백 문자입니다. 그래서 문자열은 각 공백에서 나뉘어집니다.
217 |
218 | 다음 re.split 함수는 더 강력해서, 이 함수를 사용하면 구분자(delimiter) 대신에 정규 표현식을 제공할 수 있습니다. 정규 표현식은 한 모둠의 문자열들을 지정하는 방법입니다. 예를 들어, [A-z]는 모든 문자들의 모둠이고 [0-9]는 모든 숫자들의 모둠입니다. ^연산자는 모둠을 부인합니다. 그래서 [^0-9]는 숫자가 아닌 모든 것의 모둠이며, 바로 이 모둠을 사용하여 후위 표현식을 분리하고자 합니다:
260 | 첫 번째 조건은 공백과 빈 문자열을 처리합니다. 이후의 두 조건은 연산자(operators)를 처리합니다. 현재, 다른 모든 것은 반드시 피연산자라고 가정합니다. 물론, 잘못된 입력을 점검하고 에러 메시지를 보고하는 것이 더 좋겠지만 나중에 그것을 다루어 보겠습니다.
261 |
262 |
263 | 다음 후위식 (56+47)*2 형태를 평가함으로써 이 평가기를 테스트해 봅시다:
275 | ADT의 기본적인 목표중 하나는 ADT를 구현하는 코드를 작성하는 프로바이더의 관심과 그 ADT를 사용하는 클라이언트의 관심을 분리하는 것입니다. 프로바이더는 오직 구현이---그 ADT의 규격에 맞추어서---올바른 지에 대해서만 걱정하면 됩니다. 그 구현이 어떻게 사용될지는 걱정할 필요가 없습니다.
276 |
277 | 반대로, 클라이언트는 ADT의 구현이 올바르다고 가정(assumes)합니다. 그리고 그 세부사항들은 걱정하지 않습니다. 파이썬의 내장 유형중 하나를 사용하면 오로지 클라이언트로서만 생각하면 되는 즐거움을 만끽할 수 있습니다.
278 |
279 |
280 | 물론, ADT를 구현할 때 그것을 테스트하기 위한 클라이언트 코드도 작성할 필요가 있습니다. 이 경우에 둘 모두의 역할을 수행해야하고, 이것은 혼란스러울 수 있습니다. 어느 순간에나 어떤 역할을 수행하고 있는지를 추적 유지하도록 노력해야 합니다.
281 |
282 |
283 |
18.9 용어 해설
284 |
285 |
286 |
287 |
추상적 데이타 형 (ADT)
288 |
한 모둠의 연산에 의해서 정의되지만 다양한 방식으로 구현이 가능한 데이타 유형 (보통 객체의 집단).
289 |
290 |
접근방식(interface)
291 |
ADT를 정의하는 연산들의 모둠.
292 |
293 |
구현(implementation)
294 |
한 접근방식에 대한 구문적 요구조건과 의미구조적 요구조건을 만족하는 코드.
295 |
296 |
클라이언트(client)
297 |
ADT를 사용하는 프로그램 (또는 그것을 작성한 사람).
298 |
299 |
제공자(provider)
300 |
ADT를 구현하는 코드 (또는 그것을 작성한 사람).
301 |
302 |
겉껍질(veneer)
303 |
다른 메쏘드들을 때로는 약간 변경하여 호출하는 메쏘드 정의들로서 ADT가 구현된 클래스 정의. 겉껍질(veneer)은 크게 중요한 작업은 아니지만, 클라이언트의 접근방식을 표준화하고 개선한다.
304 |
305 |
총괄 데이타 구조(generic data structure)
306 |
어떤 종류의 데이타도 담을 수 있는 일종의 데이타 구조.
307 |
308 |
중위식(infix)
309 |
두 피연산자 사이에 연산자를 놓아 수학적 표현식을 작성하는 방식.
310 |
311 |
후위식(postfix)
312 |
피연산자들 뒤에 연산자를 놓아 수학적 표현식을 작성하는 방식.
313 |
314 |
해석(parse)
315 |
문자들 또는 토큰들의 문자열을 읽어서 그의 문법적 구조를 분석하는 것.
316 |
317 |
토큰(token)
318 |
319 | 해석의 목적으로 한단위로 취급되는 한 모둠의 문자들, 자연 언어에서는 단어와 같다.
320 |
321 |
구분자(delimiter)
322 |
토큰을 분리하기 위하여 사용되는 문자, 자연언어에서는 구두점과 같다.
323 |
324 |
325 |
326 |
연습문제
327 |
328 |
329 |
후위식 알고리즘을 표현식 1 2 + 3 *에 적용하라.
330 |
331 |
332 | 이 예제는 후위식의 장점중 하나를 보여준다 --- 즉 연산 순서를 제어하기 위하여 괄호를 사용할 필요가 없다. 중위식으로 같은 결과를 얻으려면 (1 + 2) * 3으로 작성해야 한다.
52 | 이 장에서는 두 개의 ADT를 표현해 보고자 합니다: 큐(Queue)와 우선순위 큐(Priority Queue)가 그것입니다. 실제 세계에서 큐(queue)는 서비스를 기다리는 고객들의 줄과 같습니다. 대부분의 경우, 줄에 있는 첫 번째 고객이 서비스해 줄 다음 고객입니다. 그렇지만, 예외가 있습니다. 공항에서 비행기가 바로 출발하는 고객들은 가끔 그 줄의 중간에서 탑승 수속을 받습니다. 슈퍼마켓에서 정중한 고객은 몇 개 안되는 물건을 가진 고객에게 자리를 양보합니다.
53 |
54 | 누가 먼저 가야하는지를 결정하는 그 규칙을 줄서기 규칙(queueing discipline)이라고 부릅니다. 가장 간단한 줄서기 규칙은 FIFO라고 부르는데, "선-입-선-출(first-in-first-out)"을 뜻합니다. 가장 일반적인 줄서기 규칙은 우선순위 줄서기(priority queueing)입니다. 이 규칙에서 각 고객은 우선권을 할당받고, 도착 순서에 상관없이 최고순위의 우선권을 가진 고객이 먼저 서비스됩니다. 이것이 가장 일반적인 규칙이라고 말하는 이유는 우선순위가 어떤 것에라도 기초할 수 있기 때문입니다: 몇 시에 비행기가 이륙하는가; 얼마나 많은 채소를 고객이 가지고 있는가; 또는 그 고객이 얼마나 중요한가. 물론, 모든 줄서기 규칙이 "공정"한 것은 아닙니다. 그러나 공정함이란 보는 사람의 눈에 따라 다릅니다.
55 |
56 | 큐 ADT와 우선순위 큐 ADT는 연산 모둠이 같으며 접근방식도 같습니다. 차이는 연산의 의미구조에 있습니다: 큐는 FIFO 정책을 사용합니다; (그 이름이 암시하는 바와 같이) 우선순위 큐는 우선순위 줄서기 정책을 사용합니다.
57 |
58 | 대부분의 ADT에서와 마찬가지로 수 많은 방법으로 큐를 구현합니다. 큐는 항목들의 집단이므로 집단을 저장하는 모든 기본적인 메카니즘을 사용할 수 있습니다: 배열(arrays)이나 리스트(lists) 또는 벡터(vectors)가 그것입니다. 어떤 것을 선택할지는 부분적으로 수행속도에, 즉 원하는 연산을 수행하는데에 얼마나 걸리는가에 기초할 것입니다. 또 부분적으로 구현의 용이성에, 즉 얼마나 쉽게 구현할 수 있는가에 기초할 것입니다.
59 |
60 |
61 |
62 |
63 |
19.1 큐 ADT
64 |
65 |
큐 ADT는 다음의 연산으로 정의합니다:
66 |
67 |
68 |
69 |
__init__
70 |
빈 큐를 새롭게 초기화한다.
71 |
72 |
insert
73 |
큐에 항목을 새롭게 추가한다.
74 |
75 |
remove
76 |
큐로부터 항목을 제거하고 돌려준다. 반환되는 항목은 제일 먼저 추가된 항목이다.
77 |
78 |
isEmpty
79 |
큐가 비어 있는지 점검한다.
80 |
81 |
82 |
83 |
84 |
19.2 연결 큐(Linked Queue)
85 |
86 | 처음으로 보게될 큐 ADT는 연결 큐(linked queue)라고 부릅니다. 왜냐하면 이 큐는 연결된 Node 객체들로 구성되기 때문입니다. 다음과 같이 클래스를 정의합니다:
118 | isEmpty 메쏘드와 remove 메쏘드는 LinkedList의 isEmpty 메쏘드와 removeFirst 메쏘드와 동일합니다. insert 메쏘드는 새로운 것이고 약간 더 복잡합니다.
119 |
120 | 새로운 항목을 리스트의 끝에 삽입하고 싶습니다. 큐가 비어 있으면 그냥 head가 그 새로운 노드를 가리키도록 설정하기만 하면 됩니다.
121 |
122 | 그렇지 않으면, 리스트를 마지막 노드까지 순회하여 그 새로운 노드를 마지막에 붙입니다. 마지막 노드를 식별할 수 있습니다. 왜냐하면 그의 next 속성이 None이기 때문입니다.
123 |
124 | 적절하게 만들어진 Queue 객체에는 불변량이 두 개 있습니다. length의 값은 큐에 있는 노드의 개수가 되어야 합니다. 그리고 마지막 노드의 next는 None과 동등하여야 합니다. 이 메쏘드가 이 두개의 불변량을 유지하는지 직접 확인해 보세요.
125 |
126 |
127 |
19.3 수행속도의 특징
128 |
129 | 메쏘드를 호출할 때 보통 구현의 세부사항에 대해서는 신경쓰지 않습니다. 그러나 꼭 알고 싶은 "세부사항" 하나가 있습니다---그 메쏘드가 가지는 수행속도의 특징이 그것입니다. 얼마나 오래 걸리는가 그리고 집단에서 항목의 개수가 증가함에 따라 실행시간은 어떻게 변하는가?
130 |
131 | 먼저 remove를 살펴 봅시다. 여기에는 회돌이나 함수가 없습니다. 그래서 언제나 이 메쏘드의 실행시간은 동일하다는 것을 알 수 있습니다. 이러한 메쏘드를 상수-시간(constant-time) 연산이라고 부릅니다. 실제로, 이 메쏘드는 리스트가 비어 있을 때 조건 판단을 하는 몸체를 건너 뛰므로 약간 더 빠를 수도 있습니다. 그러나 그 차이는 큰 의미가 없습니다.
132 |
133 | insert의 수행은 대단히 다릅니다. 일반적인 경우에는 리스트를 순회하여 마지막 요소를 찾아야 합니다.
134 |
135 | 이 순회는 리스트의 길이에 비례하여 시간이 걸립니다. 실행시간은 길이에 대하여 선형적인 함수이므로 이러한 메쏘드를 선형 시간(linear time)이라고 부릅니다. 상수 시간에 비교하면 성능이 아주 나쁩니다.
136 |
137 |
138 |
139 |
140 |
19.4 개량된 연결 큐
141 |
142 | 모든 연산이 상수시간에 실행될 수 있도록 큐 ADT를 구현하고자 합니다. 그렇게 하는 한 가지 방법은 큐 클래스를 수정하여 첫 번째 노드와 마지막 노드에 대한 참조점을 유지하도록 하는 것입니다. 다음 그림에서 보여지는 바와 같이 말입니다:
198 | 이 구현은 연결 큐(Linked Queue) 구현보다 더 복잡합니다. 그리고 그것이 옳다는 것을 보여주기는 더욱 어렵습니다. 장점이라면 목적을 달성했다는 것입니다---insert와 remove모두 상수-시간 연산입니다.
199 |
200 |
연습으로, 파이썬의 리스트를 사용하여 연결 큐 ADT의 구현을 작성해 보세요. 이 구현의 수행속도를 일정 길이의 큐에 대하여 ImprovedQueue와 비교해 보세요.
201 |
202 |
203 |
19.5 우선순위 큐(Priority queue)
204 |
205 | 우선순위 큐 ADT는 큐 ADT와 접근방식이 같습니다. 그러나 의미구조가 다릅니다. 다시, 그 접근방식을 다음에 보여드립니다:
206 |
207 |
208 |
209 |
__init__
210 |
빈 큐를 새로이 초기화한다.
211 |
212 |
insert
213 |
항목 하나를 큐에 새롭게 추가한다.
214 |
215 |
remove
216 |
큐로부터 항목을 제거하고 반환한다. 반환되는 항목은 최고 우선순위를 가진 항목이다.
217 |
218 |
isEmpty
219 |
큐가 비었는지 점검한다.
220 |
221 |
222 |
223 |
224 | 의미구조의 차이는 큐로부터 제거되는 그 항목이 반드시 제일 처음에 추가되었던 항목이어야 할 필요는 없다는 것입니다. 오히려 그것은 큐에서 최고 우선순위를 가지는 항목입니다. 우선순위 큐 구현은 우선순위가 무엇인지 그리고 각각의 항목을 어떻게 비교할지를 지정하지 않습니다. 그것은 큐에 있는 항목들에 달려 있습니다.
225 |
226 | 예를 들어, 만약 큐에 있는 항목들이 이름을 가진다면, 항목들을 알파벳 순서로 선택할 수 있습니다. 만약 볼링 점수라면, 고득점에서 저득점 순서로 선택할 수 있습니다, 그러나 만약 골프 점수라면, 저득점에서 고득점 순서로 선택할 것입니다. 큐에 있는 항목들을 비교할 수 있는 한, 최고 우선순위를 가진 항목을 찾아서 제거할 수 있습니다.
227 |
228 | 다음 우선순위 큐(Priority Queue) 구현은 항목들을 큐에 담고 있는 파이썬 리스트를 속성으로 가집니다.
282 | 큐가 단순한 숫자 혹은 문자열을 가지고 있다면, 항목들은 수치 순서 혹은 알파벳 순서로 위로부터 아래로 제거됩니다. 파이썬은 내장 비교 연산자를 사용하여 비교할 수 있으므로 가장 큰 정수 또는 문자열을 찾을 수 있습니다.
283 |
284 | 큐가 객체 유형이라면 __cmp__ 메쏘드를 제공해야 합니다. > 연산자를 사용하여 항목들을 비교할 때, remove는 __cmp__를 항목들 중의 하나에 대하여 요청하고 다른 항목을 매개변수로 건넵니다. __cmp__ 메쏘드가 올바르게 작동하는 한, 우선순위 큐(Priority Queue)는 작동할 것입니다.
285 |
286 |
287 |
19.6 Golfer 클래스
288 |
289 | 우선순위를 특이하게 정의하는 객체의 한 예로서, Golfer라고 부르는 클래스 하나를 구현해 봅시다. 이 클래스는 골퍼의 이름과 점수를 추적 유지합니다. 보통때와 같이, __init__과 __str__을 정의함으로써 시작합니다:
41 | 자유 소프트웨어 재단(Free Software Foundation)의 철학으로 말하면 이 책은 자유 강연과 같은 자유이지 공짜 맥주와 같은 의미의 공짜가 아닙니다. 이 책은 협동작업으로 탄생하였으며 GNU 자유 문서 라이센스(GNU Free Documentation License)가 없었다면 태어나지 못했을 것입니다. 그래서 자유 소프트웨어 재단에 이 라이센스를 개발해 준 것에 대하여, 또 물론 그 라이센스를 사용할 수 있도록 허용해 준 것에 대해서 감사를 드리는 바입니다.
42 |
43 |
44 | 날카로운-눈을 가진 사려깊은, 백 여명이 넘는 독자들에게 지난 수 년간 제안과 교정을 보내 주심에 감사를 드리는 바입니다. 자유 소프트웨어의 정신에 의하여 공헌자 목록의 형태로 고마운 마음을 전하기로 결정하였습니다. 불행하게도 공헌자 목록은 완전하지 않습니다. 그러나 최선의 노력을 다하여 갱신하고 있습니다.
45 |
46 |
47 | 공헌자 목록을 훓어 볼 기회가 된다면 여기에 있는 한분 한분이 시간을 할애해 주셨다는 것을 기억해 주시기를 바랍니다. 그분들이 잠시 시간을 내어 도움을 주신 덕분에 독자들이 기술적인 에러와 애매모호한 설명 때문에 혼란에 빠지지 않고 이 글을 읽을 수 있게 되었습니다.
48 |
49 |
50 | 이렇게 수 많은 교정을 거쳤으므로 불가능하긴 하겠지만 혹시라도 이 책에는 여전히 에러가 있을 수 있습니다. 만약 에러를 발견하신다면 잠깐만 시간을 내셔서 연락을 주실 것을 부탁드립니다. 전자우편 주소는 feedback@thinkpython.com입니다. 여러분의 제안으로 수정을 하게 된다면 (빼 달라고 요구하지 않는 한) 다음 버전의 공헌자 목록에 올려 드리겠습니다. 감사합니다!
51 |
52 |
53 |
54 |
Lloyd Hugh Allen sent in a correction to Section 8.4.
55 |
56 |
Yvon Boulianne sent in a correction of a semantic error in Chapter 5.
57 |
58 |
Fred Bremmersubmitted a correction in Section 2.1.
59 |
60 |
Jonah Cohen wrote the Perl scripts to convert the LaTeX source for this book into beautiful HTML.
61 |
62 |
Michael Conlon sent in a grammar correction in Chapter 2 and an improvement in style in Chapter 1, and he initiated discussion on the technical aspects of interpreters.
63 |
64 |
Benoit Girard sent in a correction to a humorous mistake in Section 5.6.
65 |
66 |
Courtney Gleason and Katherine Smith wrote horsebet.py, which was used as a case study in an earlier version of the book. Their program can now be found on the website.
67 |
68 |
Lee Harr submitted more corrections than we have room to list here, and indeed he should be listed as one of the principal editors of the text.
69 |
70 |
James Kaylin is a student using the text. He has submitted numerous corrections.
71 |
72 |
David Kershaw fixed the broken catTwice function in Section 3.10.
73 |
74 |
Eddie Lam has sent in numerous corrections to Chapters 1, 2, and 3. He also fixed the Makefile so that it creates an index the first time it is run and helped us set up a versioning scheme.
75 |
76 |
Man-Yong Lee sent in a correction to the example code in Section 2.4.
77 |
78 |
David Mayo pointed out that the word "unconsciously" in Chapter 1 needed to be changed to "subconsciously".
79 |
80 |
Chris McAloon sent in several corrections to Sections 3.9 and 3.10.
81 |
82 |
Matthew J. Moelter has been a long-time contributor who sent in numerous corrections and suggestions to the book.
83 |
84 |
Simon Dicon Montford reported a missing function definition and several typos in Chapter 3. He also found errors in the increment function in Chapter 13.
85 |
86 |
John Ouzts sent in a correction to the "return value" definition in Chapter 3.
87 |
88 |
Kevin Parks sent in valuable comments and suggestions as to how to improve the distribution of the book.
89 |
90 |
David Pool sent in a typo in the glossary of Chapter 1, as well as kind words of encouragement.
91 |
92 |
Michael Schmitt sent in a correction to the chapter on files and exceptions.
93 |
94 |
Robin Shaw pointed out an error in Section 13.1, where the printTime function was used in an example without being defined.
95 |
96 |
Paul Sleigh found an error in Chapter 7 and a bug in Jonah Cohen's Perl script that generates HTML from LaTeX.
97 |
98 |
Craig T. Snydal is testing the text in a course at Drew University. He has contributed several valuable suggestions and corrections.
99 |
100 |
Ian Thomas and his students are using the text in a programming course. They are the first ones to test the chapters in the latter half of the book, and they have make numerous corrections and suggestions.
101 |
102 |
Keith Verheyden sent in a correction in Chapter 3.
103 |
104 |
Peter Winstanley let us know about a longstanding error in our Latin in Chapter 3.
105 |
106 |
Chris Wrobel made corrections to the code in the chapter on file I/O and exceptions.
107 |
108 |
Moshe Zadka has made invaluable contributions to this project. In addition to writing the first draft of the chapter on Dictionaries, he provided continual guidance in the early stages of the book.
109 |
110 |
Christoph Zwerschke sent several corrections and pedagogic suggestions, and explained the difference between gleich and selbe.
111 |
112 |
James Mayer sent us a whole slew of spelling and typographical errors, including two in the contributors list.
113 |
114 |
Hayden McAfee caught a potentially confusing inconsistency between two examples.
doctest는 파이썬 표준 라이브러리의 모듈로서 파이썬의 문서화 문자열과 상호대화 쉘 그리고 내부검사 능력을 혁신적으로 사용한다.
51 |
52 |
53 |
54 |
문서화문자열(docstrings)
55 |
56 |
57 | 파이썬의 문서화문자열(docstring)은 모듈과 클래스 그리고 메쏘드와 함수를 손쉽게 문서화하는 방법을 제공한다. 문서화문자열은 그냥 문자열 상수로서 한 객체의 정의에서 첫 서술문에 나타난다. 다음은 트리에 관한 장에서 가져온 예로서 그의 사용법을 보여준다:
58 |
59 |
60 |
61 | def total(tree):
62 | """total(tree) -> sum
63 |
64 | Return the sum of the values of the elements of a tree of numbers.
65 | """
66 | if tree == None: return 0
67 | return total(tree.left) + total(tree.right)
68 |
69 |
70 |
71 | 위의 예제가 trees.py이라는 모듈이라고 가정하면, 이제 다음과 같이 할 수 있다:
72 |
73 |
74 | >>> from trees import *
75 | >>> print total.__doc__
76 | total(tree) -> sum
77 |
78 | Return the sum of the values of the elements of a tree of numbers.
79 |
80 |
81 |
82 |
83 |
doctest 모듈
84 |
85 |
86 | doctest 모듈은 파이썬 2.3에서 도입되었다. 파이썬 핵심 개발자 팀 피터스(Tim Peters)가 만든 doctest 모듈은 프로그래머가 문서화문자열을 사용하여 테스트를 자동화할 수 있도록 해 준다.
87 |
GNU 자유 문서 라이선스 GNU Free Documentation
36 | License
38 |
42 |
43 |
44 |
45 |
46 |
47 |
This is an unofficial translation of the GNU Free Documentation License
48 | into Korean. It was not published by the Free Software Foundation, and does
49 | not legally state the distribution terms for documents that uses the GNU FDL
50 | -- only the original English text of the GNU FDL does that. However, we hope
51 | that this translation will help Korean speakers understand the GNU FDL
52 | better.
이 문서는 GNU 자유 문서 라이선스(GNU Free Documentation License)가 내포하고 있는 호혜적인 자유와 공유의
57 | 정신을 보다 많은 사람들에게 알리기 위한 희망에서 작성되었지만, 자유 소프트웨어 재단의 공식 문서로 취급될 수는 없다. 이는 원래의 문서가
58 | 의도하고 있는 내용이 왜곡되지 않고 법률적으로 유효하기 위해서 선행되어야 할 양국의 현행 법률과 언어의 적합성 여부에 대한 전문가들의 검토
59 | 작업에 많은 비용이 필요하기 때문이다. 따라서, 자유 소프트웨어 재단은 오역이나 해석상의 난점으로 인해서 발생될 지도 모를 분쟁의 가능성을
60 | 미연에 방지하고, 문서가 담고 있는 내용과 취지를 보다 많은 사람들에게 홍보하려는 상반된 목적을 한국어 번역문을 공식적으로 승인하지 않음으로써
61 | 양립시킬 수 있을 것이다.
62 |
자유 소프트웨어 재단은 GNU 자유 문서 라이선스를 실무에 적용할 경우, 오직 영문판 GNU 자유 문서 라이선스에 의해서만 그 법률적
63 | 효력이 올바르게 발생될 수 있음을 권고하고 있다. 이 번역문은 법률적 검토와 문서간의 동일성 여부에 대한 검증을 거치지 않은 것이며, 이로
64 | 인해서 야기될 수 있을 지도 모를 법률적 문제에 대해서 어떠한 형태의 보증도 제공하지 않는다.
65 |
Copyright (C) 2000 Free Software Foundation, Inc.
86 | 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
87 | 저작권과 사용 허가에 대한 본 사항이 명시되는 한,
88 | 어떠한 정보 매체에 의한 본문의 전재나 발췌도 무상으로 허용된다.
89 | 단, 원문에 대한 수정과 첨삭은 허용되지 않는다.
90 |
91 |
92 |
93 |
제0조. 전문(前文)
94 |
이 라이선스의 목적은 첫째, 매뉴얼이나 책 또는 다른 문서들을 "자유"롭게 만들기 위한 것이다. 여기서 말하는 "자유"란 무료라는 의미가
95 | 아닌 구속되지 않는다는 관점에서의 자유를 말한다. 즉, 상업적이든 비상업적이든 간에 누구나 그것을 수정하거나 그렇지 않은 상태에서 복제 및
96 | 재배포할 수 있는 실질적인 자유를 보장하기 위한 것이다. 둘째, 이 라이선스는 저작자나 발행인에게 다른 사람들이 가한 수정에 책임지지 않고
97 | 그들의 저작물에 대한 공로를 인정 받을 수 있는 길을 보장하기 위한 것이다.
98 |
이 라이선스는 일종의 "카피레프트"이다. 즉, 문서의 2차적 저작물 또한 같은 의미에서 자유로워야 한다는 것을 의미한다. 이것은 자유
99 | 소프트웨어를 위해서 고안된 카피레프트 라이선스인 GNU General Public License를
101 | 보완한다.
102 |
자유 소프트웨어는 자유 문서를 필요로 하기 때문에 이 라이선스는 자유 소프트웨어 매뉴얼에 사용되기 위해서 고안되었다. 자유 프로그램에는
103 | 소프트웨어에서와 같은 자유가 제공되는 매뉴얼이 함께 수반되어야 한다. 그러나, 이 라이선스가 단지 소프트웨어 매뉴얼에만 한정되는 것은 아니다.
104 | 이것은 문서의 주제나 그것이 인쇄물로 발행되었는가의 여부에 상관없이 모든 종류의 문서 저작물에 사용될 수 있다. 교육이나 참고를 목적으로 하는
105 | 저작물에는 원칙적으로 이 라이선스를 사용할 것을 추천한다.
106 |
107 |
108 |
제1조. 적용 범위와 정의
109 |
본 라이선스는 GNU 자유 문서 라이선스(GNU Free Documentation License, 이하, GNU 자유 문서 라이선스라고
110 | 명칭한다.)의 규정에 따라 배포될 수 있다는 사항이 저작권자에 의해서 명시된 모든 매뉴얼과 문서 저작물에 적용될 수 있으며, 공중의 누구라도
111 | 피양도자가 될 수 있다. 본 라이선스에서 사용되는 [문서(文書, document)]는 GNU 자유 문서 라이선스에 의해서 양도된
112 | 매뉴얼 또는 문서 저작물의 의미한다. 또한, [공중(公衆, public)]이란 불특정 다수의 사람을 의미하고,
113 | [피양도자(被讓渡者, licensee)]란 GNU 자유 문서 라이선스에 의해서 매뉴얼 또는 문서 저작물을 양도받은 사람을 의미한다.
114 | 복제 또는 개작의 대상이 되는 독자적인 문서 창작물의 최초 발행물은 [원문서(原文書, original document)]라고 한다.
115 |
116 |
문서의 [수정판(修正版, modified version)]이란, [원문서] 그대로 복제 또는 개작되거나, 다른
117 | 언어로 번역된 문서의 전부나 일부를 포함하고 있는 저작물을 의미한다.
118 |
문서의 [2차구성부(二次構成部, secondary section)]란, 문서의 저작자나 발행인과 문서의 전체 주제(또는 관련
119 | 내용)와의 관계만을 설명하거나, 문서의 전체 주제와 직접적인 관계가 없는 내용을 포함하고 있는 머리말과 목차 등의 서두나 부록 부분을 가리킨다.
120 | (예를 들면, 문서가 수학 교과서의 일부였을 경우, 이 문서의 [2차구성부]는 수학에 관련된 어떠한 내용도 기술되어서는 안된다.)
121 | [2차구성부]에 포함될 수 있는 내용은 문서의 주제나 관련 사항에 대한 개정 이력이나 법률적, 상업적, 철학적, 윤리적, 정치적
122 | 입장 등이다.
123 |
[변경불가부분(變更不可部分, invariant section]이란, 문서가 본 라이선스에 의해서 배포된다는 사실이, 해당
124 | 부분이 [변경불가부분]이라는 제목과 함께 명시된 2차 구성부의 한 형태를 의미한다.
125 |
[표지구절(表紙句節, cover texts)]이란, 문서가 본 라이선스에 의해서 배포된다는 사실이 문서의 앞 표지나 뒷 표지에
126 | 언급되는 짧은 문장을 의미한다.
127 |
문서의 [투명(透明, transparent )] 복제물이란, 사양이 공중에게 공개되어 있고, 일반적인 문서 편집기, (픽셀로
128 | 구성된 이미지의 경우) 일반적인 페인트 프로그램, (그림의 경우) 널리 사용되는 그림 편집기로 그 내용을 출력시키거나 직접 수정하기에 용이하며,
129 | 조판 프로그램(text formatter)에 입력하기에 적당하거나 조판 프로그램에 입력할 수 있는 다양한 형태의 포맷으로 자동으로 번역되기에
130 | 용이한 형태로 만들어진 기계 판독 가능한 복제물을 의미한다. 피양도자가 문서를 개작하는 것을 방해하거나 금지하기 위해서 조판 형태를 설계한 파일
131 | 포맷은 [투명]한 것이 아니다. [투명] 복제물이 아닌 것을 [불투명(不透明, opaque)] 복제물이라고
132 | 한다.
133 |
투명 복제물로 적절한 포맷의 예는 마크업(markup)이 포함되지 않은 평범한 ASCII 포맷과 Texinfo 입력 포맷, LaTeX 입력
134 | 포맷, 공개적으로 이용되는 DTD를 사용하는 SGML이나 XML, 그리고 표준 규약을 준수하는 간단한 형식의 HTML과 같이 사람이 직접 개작할
135 | 수 있는 형태의 포맷이다. 불투명 복제물에는 PostScript와 PDF, 독점 워드 프로세서에서만 읽고 편집할 수 있는 독점 포맷, 일반적으로
136 | 통용되지 않는 DTD와 처리 도구가 필요한 SGML 및 XML 포맷, 그리고 출력 목적만을 위해서 워드 프로세서로 생성한 기계 생성 HTML
137 | 포맷이 포함된다.
138 |
[제목 페이지(title page)]란, 인쇄된 책의 경우에는 문서의 제목이 표시된 페이지 자체뿐만 아니라, 보다 쉽게
139 | 이해되는데 필요하다고 판단되어 본 라이선스가 제목 페이지에 함께 포함시킬 것을 규정한 후속 페이지들을 모두 의미한다. 제목 페이지가 없는
140 | 저작물의 경우, 제목 페이지는 본문이 시작되기 전에 저작물의 제목에 가장 근접한 형태가 나타난 페이지를 의미한다.
141 |
142 |
143 |
제2조. 동일 복제
144 |
문서의 피양도자는 본 라이선스에 어떠한 사항도 추가하지 않은 상태에서, 본 라이선스와 저작권 사항 그리고 문서의 모든 복제물에 본
145 | 라이선스가 동일하게 적용된다는 사항을 명시하고 이를 문서의 복제물과 함께 제공하는 한, 어떠한 정보 매체에 의해서도 상업적이나 비상업적인
146 | 목적으로 문서를 복제하거나 배포할 수 있다. 문서를 복제하거나 배포할 경우에는 임의의 피양도자가 문서를 열람하거나 복제할 수 없도록 방해하거나
147 | 통제할 수 있는 어떠한 기술적 수단도 사용해서는 안된다. 그러나 복제물을 제공하는데 따른 보상을 청구할 수는 있다. 만약, 충분히 많은 양의
148 | 복제물을 배포할 경우에는 제3조의 규정들을 함께 준수해야만 한다.
149 |
또한 위의 조건을 준수하는 한, 피양도자는 문서의 복제물을 대여하거나 공표(公表)할 수 있다.
150 |
151 |
152 |
제3조. 대량 복제
153 |
만약, 문서의 인쇄 복제물을 100부 이상 발행하며, 문서의 라이선스 표시가 표지 구절의 사용을 규정하고 있는 경우에는 인쇄물의 앞 표지와
154 | 뒷 표지에 삽입될 앞 표지 구절과 뒷 표지 구절이 명확하고 읽기 쉬운 형태로 모든 복제물에 포함되어야 한다. 또한 인쇄 복제물의 발행인에 대한
155 | 정보가 양쪽 표지 모두에 명확하고 읽기 쉬운 형태로 명시되어야 한다. 인쇄물의 앞 표지에는 문서의 완전한 제목이, 제목을 구성하는 모든 문자들이
156 | 동일한 수준의 식별력을 가질 수 있도록 표시되어야 한다. 복제물의 표지에는 추가적인 문장이나 도형, 그림 등의 요소를 추가하는 것이 가능하다.
157 | 문서의 제목이 유지되고 이러한 조건들을 만족하는 한, 표지만 변경시킨 복제물은 표지 이외의 다른 부분에 대한 동일 복제로 간주된다.
158 |
앞 표지나 뒷 표지에 표시될 표지 구절의 내용이 너무 많아서 읽기 힘든 경우에는 실제 표지에는 (적당한 만큼만) 기재하고, 나머지 내용들은
159 | 인접 페이지에 표시할 수 있다.
160 |
100부 이상의 불투명 복제물을 발행하거나 배포하는 경우, 모든 불투명 복제물에 기계 판독이 가능한 투명 복제물을 함께 첨부하거나, 추가된
161 | 것이 없는 완벽한 투명 복제물이 있는 공개적인 접근이 가능한 컴퓨터 네트워크의 위치를 각 불투명 복제물에 명시하여 네트워크를 사용하는 일반
162 | 공중이 공개 표준을 준수하는 네트워크 프로토콜을 이용하여 비용없이 익명으로 다운로드 받을 수 있도록 해야 한다. 후자의 경우, 불투명 복제물을
163 | 대량으로 배포하기 시작할 때에는 매우 신중한 접근을 해야 하는데, 불투명 복제물을 공중에게 (본인이 직접 또는 대리인을 통해서, 또는 소매업자를
164 | 통해서) 배포한 마지막 시점으로부터 적어도 1년 뒤까지 투명 복제물이 명시된 위치에서 접근될 수 있는 상태로 확실히 남아있도록 해야 한다.
165 |
강제 조항은 아니지만, 복제물을 대량으로 배포하기 전에 충분한 시간적 여유를 두고 문서의 저작자와 연락해서 저작자에게 문서의 최신 개정판을
166 | 제공할 수 있는 기회를 주어야 한다.
167 |
168 |
169 |
제4조. 개작
170 |
문서의 수정판은 수정판이 명백하게 본 라이선스에 의해서 관리되는 조건 하에서 제2조와 제3조의 규정에 의해서 복제 및 배포될 수 있다.
171 | 즉, 수정판은 문서의 역할을 유지해야 하며, 수정판의 복제물을 양도받은 임의의 피양도자는 개작과 배포에 대한 동일한 권리를 양수받게 된다.
172 | 또한, 수정판에 대해서 다음의 규정들을 준수해야만 한다.
173 |
174 |
175 |
A. 수정판의 제목 페이지에는 (표지가 있다면 표지에도) 문서와 그 이전 판의 문서와 구별되는 제목을 사용한다. (문서의
176 | 개정 이력란이 존재한다면 이러한 사실이 등재되어야 한다.) 이전 판의 발행인이 허락한다면, 이전 판과 같은 제목을 사용할 수 있다.
177 |
B. 수정판의 제목 페이지에는 적어도 5명의 문서의 원저작자 (5명보다 적다면 원저작자 모두)와 함께, 개작에 책임이 있는
178 | 1인 이상의 개인 또는 단체를 저작자로 명시해야 한다.
179 |
C. 수정판의 발행인 성명을 제목 페이지에 발행인으로서 명시한다.
180 |
D. 문서의 모든 저작권 표시를 수정판에 유지해야 한다.
181 |
E. 문서의 저작권 표시 부분에 자신이 개작한 것에 대한 적절한 저작권 사항을 추가해서 수정판에 표시한다.
182 |
F. 저작권 표시 바로 다음에, 본 라이선스의 규정 하에 공중이 수정판을 사용할 수 있다는 라이선스 표시를 본 라이센스의
183 | 부록에 나와있는 형식으로 포함시킨다.
184 |
G. 문서의 라이선스 표시에 포함되어 있던 변경 불가 부분의 목록과 명시할 것을 요구한 표지 구절을 수정판에도 모두 그대로
185 | 유지한다.
186 |
H. 본 라이선스를 변경 없이 그대로 포함시킨다.
187 |
I. [개정이력(履歷, history)]이라는 이름이 붙어 있는 부분과 그 제목을 그대로 유지하고, 적어도 수정판의 제목,
188 | 연도, 수정판 저작자, 발행인에 대한 항목을 제목 페이지에서 명시한 것과 동일하게 이 부분에 추가한다. 문서에 이력 부분이 없을 경우에는,
189 | 제목 페이지와 동일하게 문서의 제목과 연도, 저작자, 발행인을 명시한 이력 부분을 새롭게 만들고 앞에서 언급한 대로 수정판에 대한 사항을
190 | 추가한다.
191 |
J. 공중이 투명 복제물에 접근할 수 있게 하기 위해서 문서에 명시한 네트워크 주소가 존재한다면 이를 수정판에도 그대로
192 | 유지한다. 문서의 이전 판에 포함되어 있던 네트워크 주소가 문서에 기재되어 있는 경우에도, 이를 소급해서 수정판에 그대로 유지한다. 네트워크
193 | 주소는 개정 이력 부분에 기재될 수도 있다. 만일, 네트워크 주소가 문서보다 적어도 4년 전에 발행된 저작물을 위한 것이거나 네트워크 주소가
194 | 최초로 포함된 문서의 발행인이 허락했다면, 이를 생략할 수 있다.
195 |
K. [감사의 글(acknowledgements)] 또는 [헌사(dedications)]라는 표제를 갖고 있는 부분이
196 | 있다면, 이 부분에 기재되어 있는 제목과 기여자에 대한 감사의 글 그리고 헌사의 내용과 어조를 수정판에도 모두 유지한다.
197 |
L. 문서의 모든 변경 불가 부분은 제목과 본문을 변경하지 않고 수정판에 그대로 유지한다. 장(chapter) 또는
198 | 절(section) 번호나 이에 상당하는 것은 변경 불가 부분의 제목의 일부분으로 간주되지 않는다.
199 |
M. [추천사(endorsements)]라는 제목이 붙은 부분은 수정판에서 모두 누락시킨다. 이러한 부분이 수정판에
200 | 포함되어서는 안된다.
201 |
N. 기존의 어떠한 부분도 수정판에서 추천사로 제목을 바꾸지 말고, 제목을 개명하는 부분이 변경 불가 부분의 어떠한
202 | 제목과도 충돌되지 않도록 한다.
203 |
만일 수정판이 문서에 포함되어 있지 않던 새로운 서두 부분이나 부록을 2차 구성부의 형태로 포함하게 되면, 이러한 부분의 전체나 일부를
204 | 선택에 따라 변경 불가 부분으로 설정할 수 있다. 변경 불가 부분을 새롭게 설정하기 위해서는 수정판의 라이선스 표시 부분에 포함되어 있는 변경
205 | 불가 부분 목록에 제목을 추가시킨다. 이때, 그 제목들은 다른 부분의 제목들과 구별되어야 한다.
206 |
수정판에만 한정된 추천사가 다양한 주체들에 의해서 제공될 경우에는, 예를 들어, 동료들의 비평문이나 수정판을 특정한 표준의 권위있는 정의로
207 | 인정한다는 관련 기관의 승인이 있을 경우에는 "추천사"라는 제목의 글을 추가할 수 있다.
208 |
수정판의 표지 구절 목록 말미에는 앞 표지 구절과 뒷 표지 구절로 각각 5단어와 25단어 미만의 문장을 덧붙일 수 있다. 한 개인 또는 한
209 | 단체는 (또는 단체에 의해서 만들어진 협약을 통해서) 오직 한 개의 문장만을 각각 앞 표지 구절과 뒷 표지 구절에 추가할 수 있다. 만약,
210 | 문서의 표지 구절에 이미 특정인이나 특정인이 대표하는 단체의 협약에 의해서 포함된 문장이 존재할 경우에는 동일인에 의해서 표지 구절 문장이
211 | 추가될 수 없다. 그러나 문서의 발행인으로부터 명시적인 승인을 받은 경우에는 기존의 문장을 수정판에서 새로운 문장으로 대체할 수 있다.
212 |
문서의 저작자(들)과 발행인(들)은 본 라이선스를 통해서 수정판을 선전하는데 그들의 이름이 사용되거나, 명시적 또는 묵시적인 형태로 그들의
213 | 이름이 수정판을 추천하는데 사용되는 것을 허용한 것이 아니다.
214 |
215 |
216 |
제5조. 문서의 결합
217 |
수정판에 대해서 정의된 제4조의 규정에 따라서, 본 라이선스에 의해서 특정 문서를 다른 문서들과 결합할 수 있다. 단, 문서를 결합할 때는
218 | 결합 저작물을 구성하는 개별 문서들의 변경 불가 부분들을 결합 문서에 그대로 포함시켜야 하며, 그 목록을 결합 저작물의 저작권 표시 부분에
219 | 명시해야 한다.
220 |
결합 저작물에는 본 라이선스의 복제물 1부만 포함시키면 되며, 여러 개의 동일한 변경 불가 부분 또한 하나로 통합될 수 있다. 만약,
221 | 동일한 이름을 갖는 변경 불가 부분이 여러 개 존재하지만, 그 내용이 다른 경우에는 각각의 내용과 관련된 저작자와 발행자가 알려져 있을 경우에는
222 | 해당 정보를 각 부분의 말미에 괄호안에 명시하고 그렇지 않은 경우에는 숫자를 이용해서 구분한다. 결합 저작물의 저작권 표시 부분에 있는 변경
223 | 불가 부분 목록에 포함된 제목도 같은 방식으로 조정한다.
224 |
원문서에 존재하던 "개정 이력" 부분은 모두 통합하여, 단일한 "개정 이력" 부분을 결합 저작물 안에 유지해야 한다. "감사의 글"과
225 | "헌사"도 같은 방식으로 조정한다. 단, "추천사" 부분은 모두 삭제해야 한다.
226 |
227 |
228 |
제6조. 문서의 수집
229 |
본 라이선스 하에 배포된 문서들을 모아서 구성한 수집 저작물을 만들 수 있다. 또한, 개별 문서에 포함되어 있던 본 라이선스 복제물들을 한
230 | 개로 대체하여 수집 저작물에 포함시킬 수 있다. 이 경우, 다른 모든 부분들은 본 라이선스에 규정된 제2조 동일 복제 규정을 준수해야 한다.
231 |
수집 저작물로부터 하나의 문서를 발췌해서 개별 배포할 경우에는, 본 라이선스의 복제물을 발췌한 문서에 첨부하고 그 이외의 다른 부분들은
232 | 모두 제2조에 규정된 동일 복제 조항을 준수해야 한다.
233 |
234 |
235 |
제7조. 독자적 저작물과의 집합 저작물 구성
236 |
문서 또는 문서의 2차적 저작물을 독자적인 문서나 저작물과 함께 대량 저장 매체 또는 배포 매체에 구성한 편집물을 만들 경우에는, 저작물의
237 | 구성에 따른 편집 저작권이 주장되지 않는 한, 저작물 전체를 본 라이선스가 규정하는 수정판으로 간주하지 않는다. 이러한 편집물을 집합
238 | 저작물이라고 부르며, 편집 과정에서 문서와 함께 구성된 독자적 저작물이 문서로부터 파생된 것이 아니라면 본 라이선스가 적용되지 않는다.
239 |
제3조의 표지 구절에 대한 요구는 문서의 복제물에 적용된다. 따라서 문서의 양이 전체 편집물의 1/4 보다 작은 경우에는, 문서의 표지
240 | 구절은 편집물 안에서 문서가 위치해 있는 곳의 표지 부분에 포함되어도 무방하다. 그렇지 않은 경우에는, 표지 구절이 전체 편집물의 표지 부분에
241 | 나타나야 한다.
242 |
243 |
244 |
제8조. 번역
245 |
번역은 일종의 개작으로 간주된다. 따라서 문서의 번역물은 제4조의 규정에 따라 배포될 수 있다. 변경 불가 부분을 번역물로 대체하기
246 | 위해서는 저작권자의 명시적인 승인을 얻어야 한다. 그러나 변경 불가 부분의 전체 또는 일부에 대한 번역문을 원문과 함께 표시할 경우에는
247 | 저작권자로부터 별도의 승인을 얻을 필요가 없다. 본 라이선스의 번역판을 첨부할 경우에는 영어 원판을 함께 제공해야 한다. 영어 원판과 번역판
248 | 사이에 충돌이 발생할 경우에는 영문 원판이 우선한다.
249 |
250 |
251 |
제9조. 권리의 소멸
252 |
본 라이선스 하에 명백하게 제공된 것을 제외하고는 문서를 복제, 개작, 양도 또는 배포할 수 없다. 본 라이선스에 의하지 않고 문서를
253 | 복제, 수정, 양도, 배포하는 어떠한 시도도 무효이며 본 라이선스에 의해서 보장된 권리는 자동으로 소멸된다. 그러나, 본 라이선스에 의해서
254 | 복제물이나 권리를 양도받은 피양도자는 본 라이선스의 규정들을 모두 준수하는 한, 그 권리를 유지할 수 있다.
255 |
256 |
257 |
10. 본 라이선스의 향후 개정
258 |
자유 소프트웨어 재단은 때때로 GNU 자유 문서 라이선스의 개정판을 발행할 것이다. 개정판은 현재의 판과 그 정신에 있어서 유사하겠지만,
259 | 발생 가능한 새로운 문제나 사안을 처리하기 위해서 세부 사항에 차이가 있을 수 있다. http://www.gnu.org/copyleft/의 내용을 참고하기
261 | 바란다.
262 |
라이선스의 각 판(version)은 구별되는 판 번호(version number)를 가진다. 문서가 특정한 번호나 "또는 어떤 판 이후"가
263 | 적용된다고 라이선스의 판을 명시한 경우에는, 특정 판의 규정과 조건을 따르거나 자유 소프트웨어 재단이 발행한 후속 판(시험판이 아닌)을 따를 수
264 | 있다. 문서가 본 라이선스의 판 번호를 특정하고 있지 않다면, 자유 소프트웨어 재단에서 발행한 (초고가 아닌) 어떠한 판을 선택해도 무방하다.
265 |
266 |
267 |
본 라이선스를 실무에 적용하는 방법
268 |
작성한 문서에 본 라이선스를 적용하기 위해서는, 본 라이선스의 복제물을 문서에 첨부하고 다음과 같은 저작권 및 라이선스 표시를 제목 페이지
269 | 다음에 추가한다.
270 |
271 |
272 |
Copyright (c) 연도, 본인 성명 GNU 자유 문서 라이선스 1.1판 또는 자유 소프트웨어 재단에서
273 | 발행한 이후 판의 규정에 따라 본 문서를 복제하거나 개작 및 배포할 수 있다. 본 문서의 변경 불가 부분은 "xxx"이고 앞 표지 구절은
274 | "xxx", 뒷 표지 구절은 "xxx"이다. 본 라이선스의 전체 내용은 "GNU 자유 문서 라이선스" 부분에 포함되어 있다.
275 |
276 |
만약, 변경 불가 부분이 없는 경우라면, 변경 불가 부분을 명시하는 대신 "변경 불가 부분 없음"이라고 표시한다. 앞 표지
277 | 구절과 뒷 표지 구절이 없는 경우에도 각각 "앞 표지 구절 없음"과 "뒷 표지 구절 없음"이라는 사실을 명시한다.
278 |
만약, 문서가 프로그램 코드의 예를 상당 부분 포함하고 있다면 GNU General Public License와
280 | 같은 자유 소프트웨어 라이선스를 사용해서 프로그램 코드가 자유소프트웨어에서 사용될 수 있도록 라이선스를 병행할 것을 추천한다.
281 |
35 | 교육자이며 연구가 그리고 저자로서 본인은 기쁜 마음으로 이 책이 완성된 것을 보고 있습니다. 파이썬은 재미있고 너무나 쉽게-사용-가능한 프로그래밍 언어로서 지난 수년간 날로 인기가 치솟고 있습니다. 십 여년 전에 귀도 반 로섬에 의해서 개발된 파이썬은 그의 간결한 구문과 전체적인 느낌이 광범위하게 ABC로부터 기원합니다. ABC 언어는 1980년대에 개발된 교육용 언어입니다. 그렇지만, 파이썬은 실제 세계의 문제도 풀도록 디자인되었습니다. 그리고 C++과 자바 그리고 모듈라-3와 스킴 같은 프로그래밍 언어로부터도 다양한 사양을 빌려왔습니다. 이 덕분에 파이썬에서 가장 눈에 띠는 특징중 하나는 파이썬이 전문 소프트웨어 개발자, 과학자, 연구원, 기술자, 그리고 교육자들에게 매력적이라는 것입니다.
36 |
37 | 파이썬이 여러 많은 공동체에 매력적임에도 불구하고, 여전히 당신은 궁금할지도 모르겠습니다. "왜 파이썬이지?" 또는 "왜 파이썬으로 프로그래밍을 가르쳐야 하지?" 이러한 질문에 대답하는 것은 쉬운 일이 아닙니다 --- 특히 대중적인 의견이 C++이나 자바 같은 자학적인 대안 언어의 편에 있다면 말이지요. 그렇지만 가장 직접적으로 대답하면 파이썬으로 프로그래밍 하는 것이 그냥 대단히 재미있고 더 생산적이기 때문입니다.
38 |
39 | 컴퓨터 과학 강좌를 가르칠 때 본인은 강좌의 내용을 학생들에게 흥미롭고 매력적으로 만드는 것 말고도 중요한 개념들을 다루기를 원합니다. 불행하게도 개론적인 프로그래밍 강좌에서 수학적인 추상화에 너무 많이 초점을 맞추는 경향이 있으며 학생들은 구문과 컴파일 그리고 비밀스런 규칙들을 강요하는 저-수준 세부사항에 관련된 문제들 때문에 고민하면서 좌절감에 빠지는 경향이 있습니다. 그러한 추상화와 형식주의가 전문적인 소프트웨어 기술자들과 앞으로 컴퓨터 과학을 계속해서 공부할 계획이 있는 학생들에게는 중요할지 모릅니다. 그러나 개론적인 강좌에서 그러한 접근법을 취하면 대부분 컴퓨터 과학을 지루한 과목으로 만드는데나 성공할 뿐입니다. 강좌를 가르치면서 나는 느낌이 없는 학생들이 자리를 차지하는 것을 원하지 않습니다. 나는 학생들이 흥미로운 문제들을 풀려고 노력하는 것을 즐겨 보는 편입니다. 학생들은 서로 다른 아이디어들을 탐험해보고 비관례적인 접근법을 취해보며 규칙을 어겨보고 실수를 통해 배웁니다. 그러지 못하고 불분명한 구문 문제들이나 지능적이지 못한 컴파일러 에러 메시지들 또는 프로그램의 수 백 가지 일반 보호 오류를 걸러 내면서 한 학기의 절반을 허비하는 것을 본인은 원하지 않습니다.
40 |
41 | 내가 파이썬을 좋아하는 이유는 파이썬이 정말로 실제세계와 개념세계 사이에 훌륭하게 균형을 이룬다는 것입니다. 파이썬은 인터프리터이기 때문에 초보자들은 컴파일과 링크라는 문제에서 길을 잃고 해멜 필요없이 파이썬을 선택하는 그 즉시 깔끔하게 작업을 시작할 수 있습니다. 게다가, 파이썬에는 방대한 라이브러리 모듈이 있어서 웹-프로그래밍에서부터 그래픽까지 아우르는 온갖 종류의 작업을 할 수 있습니다. 실제적인 문제에 초점을 두는 것은 학생들을 이끄는 훌륭한 방법입니다. 그리고 그렇게 함으로써 학생들은 의미있는 프로젝트를 완성할 수 있습니다. 그렇지만 파이썬은 또 중요한 컴퓨터 과학 개념들을 소개하기 위한 훌륭한 토대로 기여할 수 있습니다. 파이썬은 프로시저와 클래스를 완벽하게 지원하므로 학생들은 절차적인 추상화와 데이타 구조 그리고 객체-지향 프로그래밍과 같은 주제들과 차근차근 만날 수 있습니다---이 모든 것들은 나중에 자바 또는 C++ 강좌에 적용할 수 있습니다. 파이썬은 기능적 프로그래밍 언어로부터도 수 많은 특징을 빌려왔으며 이 덕분에 나중에 스킴과 리스프 강좌에서 더욱 자세하게 다루어질 개념들을 소개할 수 있습니다.
42 |
43 | 제프리의 서문을 읽으면서 그의 논평에 감동하였습니다. 파이썬으로 그는 "더 높은 수준의 성공과 너 낮은 수준의 좌절"을 볼 수 있었으며 "더 빠르게 움직이고도 더 좋은 결과"를 얻을 수 있었습니다. 비록 이러한 논평이 그의 개론 강좌를 지칭하고 있기는 하지만, 본인 역시 정확하게 똑 같은 이유로 시카고 대학에서 대학 수준의 컴퓨터 과학 강좌에 파이썬을 자주 사용합니다. 이러한 강좌를 진행하다 보면 항상 피 말리는 9 주간의 학기 동안 서로 다른 수 많은 강의 재료들을 완수해야 한다는 엄청난 과제에 시달립니다. C++과 같은 언어를 사용하면 많은 고통과 고민을 확실하게 안겨줄 수 있지만, 나는 이러한 접근법이 비생산적이라는 것을 발견하곤 합니다---특히 강좌가 단지 "프로그래밍"에 관련되지 않은 주제에 관한 것일 때는 말이지요. 파이썬을 사용하면 나로서는 당면한 실제 주제에 더 초점을 맞출 수 있고 반면에 학생들은 가시적인 수업 프로젝트를 완성할 수 있다는 사실을 발견하였습니다.
44 |
45 | 비록 여전히 젊고 진화하고 있는 언어임에도 불구하고 파이썬은 교육 분야에 밝은 미래가 있다고 믿습니다. 이 책은 그 방향으로 중요한 한 걸음을 내딛고 있습니다.
46 |
47 | 데이비드 비즐리(David Beazley)
48 | 시카고 대학(University of Chicago)
49 | Python Essential Reference의 저자
42 | 이 책은 인터넷과 자유 소프트웨어 운동에 힘을 얻은 협동작업 덕분에 존재하고 있습니다. 이 책의 저자 세 명은 --- 대학 교수와 고등학교 교사 그리고 전문 프로그래머로서 --- 아직까지 얼굴을 마주한 적이 없습니다. 그러나 서로 밀접하게 함께 작업할 수 있었고 수 많은 훌륭한 분들이 시간과 열정을 바쳐서 이 책을 개선하는데 도움을 주셨습니다.
43 |
44 |
45 | 리차드 스톨만과 자유 소프트웨어 연합이 제시한 작업틀 안에서 서로 협력하여 탄생시킨 이 책은 미래의 가능성과 혜택을 가늠하는 좋은 시금석이라고 생각합니다.
46 |
47 |
48 |
왜 어떻게 파이썬을 사용하게 되었는가
49 |
50 |
51 | 1999년 처음으로 대학 위원회의 AP(Advanced Placement) 컴퓨터 과학 시험이 C++로 출제 되었습니다. 온 도시를 통틀어 많은 고등학교들이 사용하여 왔던 터이므로, 언어를 변경한다는 결정은 욕타운 고등 학교의 컴퓨터 과학 강의에 직접적으로 충격을 주었습니다. 제가 시무하고 있는 욕타운 고등학교는 버지니아주 알링턴시에 있습니다. 이 시점까지 파스칼이 첫-해와 AP 강좌에 사용되는 교육 언어였습니다. 학생들에게 같은 언어로 2년간 가르친다는 과거의 관례를 따르기 위하여 1997-98 년동안 C++로 바꾸기로 결정하였습니다. 그렇게 그 다음해에 대학 위원회가 AP 코스를 변경하는 것에 보조를 맞추려고 하였습니다.
52 |
53 |
54 | 2 년이 지나자 C++은 학생들에게 컴퓨터 과학을 소개하기에 좋지 않은 선택이라는 확신이 들었습니다. C++은 대단히 강력한 프로그래밍 언어이기는 하지만 또한 배우고 가르치기에 극도로 어렵습니다. C++의 어려운 구문과 다양한 처리 방법에 대하여 끊임없이 싸우고 있는 나 자신을 발견하였습니다. 그리고 결과적으로 불필요하게 많은 학생들을 잃고 있었습니다. 첫-해 강의에 더 좋은 언어를 선택할 수 있으리라는 확신을 하고서 C++을 대신할 대안을 찾았습니다.
55 |
56 |
57 | 컴퓨터실에서 사용하는 리눅스 머신 뿐만 아니라 대부분의 학생들이 집에서 사용하는 윈도우즈와 매킨토시 플랫폼에서도 실행되는 언어가 필요했습니다. 그 언어가 오픈 소스이기를 원했습니다. 그래야 학생들이 용돈에 신경쓰지 않고 집에서 그것을 사용할 수 있을 테니까요. 전문 프로그래머가 사용하는 언어를 원했습니다. 그리고 적극적인 개발자 공동체가 그 언어를 지원하기를 원했습니다. 그 언어는 절차와 객체-지향 프로그래밍 모두를 지원할 필요가 있었습니다. 그리고 무엇보다도 중요한 것은 배우기에 쉬워야 하고 가르치기에 쉬워야 했습니다. 이러한 목표들을 염두에 두고 조사를 마치고 나니까 파이썬이 목표에 가장 훌륭한 후보로 우뚝 서 있었습니다.
58 |
59 |
60 | 욕타운의 재능있는 학생중, 매트 아렌스(Matt Ahrens)에게 파이썬을 한 번 시험해 보라고 권했습니다. 두 달이 지나자 그는 그 언어를 다 배웠을 뿐만 아니라 pyTicket 이라고 부르는 어플리케이션을 작성하였습니다. 그 프로그램으로 우리 운영진은 웹을 통하여 기술적인 문제를 보고할 수 있었습니다. C++이었다면 그가 그 정도 크기의 어플리케이션을 그렇게 단기간에 작성할 수는 없었을 것이라고 확신합니다. 그가 파이썬에 적극적으로 매달려 얻은 이 성과는 파이썬이 바로 내가 찾고 있던 해결책이라는 확신을 주었습니다.
61 |
62 |
63 |
교과서를 찾아서
64 |
65 |
66 | 그 다음해 모든 컴퓨터 과학 개론 수업에 파이썬을 사용하기로 결심했습니다. 그러나 교과서가 없다는 골치 아픈 문제에 봉착했습니다.
67 |
68 |
69 | 무료 웹소가 구세주가 되어 주었습니다. 그 해 상반기에 리차드 스톨만(Richard Stallman)은 나에게 알렌 다우니(Allen Downey)를 소개해 주었습니다. 우리 둘은 리차드에게 편지를 보내어 자유 교육 웹소를 개발하는데 관심을 표명하였습니다. 알렌은 이미 신입생용 컴퓨터 과학 교과서인 컴퓨터 과학자같이 생각하는 법을 집필하였습니다. 이 책을 읽는 순간 그것을 내 수업에 사용하고 싶었습니다. 내가 본 컴퓨터 과학 교과서 중에 가장 도움이 되는 명료한 책이었습니다. 그 책은 특별한 언어의 사양보다는 프로그래밍과 연관된 사고의 과정에 초점을 맞추고 있었습니다. 그 책을 읽고 나는 더욱 훌륭한 선생님이 되었습니다.
70 |
71 |
컴퓨터 과학자같이 생각하는 법은 훌륭한 책일 뿐만 아니라 GPL(GNU public license)아래에서 배포되어 왔습니다. 이는 사용자의 필요에 맞추어 자유롭게 변경하고 사용할 수 있다는 것을 의미합니다. 파이썬을 사용하기로 결정하자 알렌의 원래 자바 버전 교과서를 새로운 언어로 번역할 수 있겠다는 생각이 들었습니다. 나 혼자로는 교과서를 집필하지 못하였을 테지만, 알렌의 책을 가지게 됨으로써 책을 집필할 수 있었으며, 동시에 소프트웨어에 잘 적용되던 협동적인 개발 모델이 교육적인 웹소에 대해서도 잘 작동한다는 것을 보여줄 수 있었습니다.
72 |
73 |
74 | 이 책에 대해서 지난 2 년 동안 작업해 오면서 나와 학생들은 많은 보상을 받았습니다. 그리고 나의 학생들이 그 과정에서 중요한 역할을 하였습니다. 누군가가 어려운 구문이나 철자 에러를 발견하면 바로바로 수정을 할수 있었으므로 그들에게 이 책에서 실수를 찾기를 독려하였으며 이 교과서에 개선을 제안할 때마다 학생들에게 보너스 점수를 주었습니다. 이렇게 하여 학생들이 더욱 세심하게 교과서를 읽도록 독려하게 되는 장점뿐만 아니라 비판적으로 교과서 전체를 검토할 수 있는 장점도 얻을 수 있었으며, 학생들은 이런 교과서를 사용하여 컴퓨터 과학을 배웠습니다.
75 |
76 |
77 | 이 책의 후반부에 있는 객체-지향 프로그래밍에 대하여 나보다는 실전 프로그래밍 경험을 가지고 있는 누군가가 정확하게 처리해줄 필요가 있다는 사실을 깨닫았습니다. 이 책은 더 좋은 웹소를 위하여 완성되지 못하고 일 년 동안을 지냈습니다. 드디어 오픈 소스 공동체가 책의 완성을 위하여 필요한 방법을 다시 제공하여 주었습니다.
78 |
79 | 크리스 메이어스(Chris Meyers)가 이 책에 관심이 있다는 전자메일을 보내 왔습니다. 그는 전문 프로그래머로서 지난 해에 오레곤주의 레인 단과대학(Lane Community College)에서 파이썬을 이용한 프로그래밍 강좌를 시작하였습니다. 강좌 계획으로 그는 이 책에 관심을 가지게 되었고, 즉시 돕기 시작하였습니다. 그 학기의 마지막에 다다를 즈음, 그는 우리의 웹 사이트 http://www.ibiblio.org/obp에 재미로 하는 파이썬이라고 부르는 동료 프로젝트를 개설하였고 나의 우수한 학생들에게 왕 선생님의 역할을 하여 주어서, 내가 이끌어 주지 못하는 높은 곳까지 학생들을 이끌어 주었습니다.
80 |
81 |
82 |
파이썬으로 하는 프로그래밍을 소개하기
83 |
84 | 지난 이 년간 컴퓨터 과학자 같이 생각하는 법을 번역하고 사용해 오면서 파이썬이 이제 시작하는 학생들에게 적절하다는 확신을 갖게 되었습니다. 파이썬은 프로그래밍 예제를 놀랍도록 단순화시켜 주며 중요한 프로그래밍 아이디어를 더 쉽게 가르치도록 하여줍니다.
85 |
86 |
87 | 이 교과서의 첫 번째 예제는 이 장점을 보여줍니다. 전통적인 "hello, world" 프로그램으로서 C++ 버전의 교과서에서는 다음과 같이 보입니다:
107 | 비록 이것이 사소한 예제일지는 모르나, 파이썬이 보여주는 장점은 명백합니다. 욕타운의 컴퓨터 과학 I 강좌는 아무런 필수조건도 요구하지 않습니다. 너무나 많은 학생들이 첫 프로그램으로 이 예제를 볼 것입니다. 어떤 학생들은 컴퓨터 프로그래밍은 배우기가 어렵다는 소문을 듣고서 약간은 긴장해 있을 것입니다. C++ 버전은 항상 나에게 만족스럽지 못한 두 개의 선택사항 중 하나를 선택하도록 강요합니다: #include, void main(), {, and }를 모두 설명해 주고서 이제 겨우 시작하는 학생들을 의기소침하게 하거나 혼란에 빠트리는 위험을 감수해야 합니다. 또는 그들에게 다음과 같이 말해줍니다, "지금으로서는 그런 모든 것들에 신경쓰지마라; 나중에 그것에 관하여 알게 될거야." 그리고 같은 위험을 감수합니다. 컴퓨터 과학 강좌의 교육 목표는 학생들에게 프로그래밍 서술문에 대한 아이디어를 소개하고 그들 만의 첫 번째 프로그램을 작성하도록 도와 주며, 그럼으로써 프로그래밍 환경을 소개해 주는 것입니다. 파이썬 프로그램은 이러한 일들을 하는데 필요한 것들을 정확하게 가지고 있습니다.
108 |
109 | 예제 프로그램을 설명한 부분을 각 버전별로 비교해 보면 이것이 시작하는 학생들에게 무엇을 의미하는 것인지 더욱 잘 알 수 있습니다. C++ 버전에서는 "Hello, world!"를 설명하는데 열 세 개의 문단이 있습니다; 파이썬 버전에서는 단 두개의 문단만 있습니다. 더욱 중요한 것은 빠진 열 한개의 문단이 컴퓨터 프로그래밍에 있어서의 "중요한 아이디어"를 다루고 있는 것이 아니라 C++ 구문의 세부사항을 다루고 있다는 것입니다. 이와 똑 같은 상황이 책 전체를 통하여 일어나는 것을 알게 되었습니다. 전체 문단이 파이썬 버전의 텍스트에서는 쉽게 사라집니다. 왜냐하면 파이썬의 더욱 명료한 구문 덕분에 그 문단은 불필요하게 되기 때문입니다.
110 |
111 |
112 | 파이썬 같이 아주 높은-수준의 언어를 사용하면 선생님들은 기계의 저-수준 세부사항에 대한 언급을 유보할 수 있으며 학생들은 그 동안 그 세부사항을 더 잘 이해하기 위해 필요한 배경(지식)을 익힐 수 있습니다. 그런식으로 교육적으로 "중요한 것을 먼저" 다루는 능력이 생깁니다. 이러한 것중 가장 훌륭한 예는 파이썬이 변수들을 다루는 방식입니다. C++에서 변수는 어떤 것을 보유하고 있는 장소에 대한 이름입니다. 변수들은 부분적으로라도 유형이 선언될 필요가 있습니다. 왜냐하면 변수들이 참조하고 있는 그 장소의 크기가 미리 결정될 필요가 있기 때문입니다. 그리하여, 변수에 대한 아이디어는 그 기계의 하드웨어에 얽매이게 됩니다. 변수에 대한 강력하고 기본적인 개념들은 시작하는 학생들에게 (컴퓨터 과학과 대수학 모두에서) 이미 충분히 어렵습니다. 바이트와 주소만으로는 도움이 되지 않습니다. 파이썬에서 변수는 어떤 것을 가리키는 이름입니다. 이것은 시작하는 학생들에게 훨씬 더 직관적인 개념이며 수학 수업시간에 배운 "변수"의 의미에 더욱 근접한 것입니다. 과거에 비해 금년에는 학생들에게 변수를 훨씬 더 쉽게 가르쳤고 변수를 사용할 때 발생하는 문제를 도와주는 시간을 훨씬 더 적게 소비하였습니다.
113 |
114 |
115 | 파이썬이 프로그래밍을 가르치고 배우는데 있어서 어떻게 도움을 주는지 보여주는 또 다른 예는 함수 구문에 있습니다. 학생들은 항상 함수를 이해하는 것을 대단히 어려워 했습니다. 주요 문제는 함수정의와 함수호출 사이의 차이 그리고 매개변수와 인자 사이의 구별에 집중됩니다. 파이썬은 아름답기까지 한 구문으로 구세주가 되어 줍니다. 함수 정의는 키워드 def로 시작합니다. 그래서 학생들에게 단순하게 말해줍니다, "네가 함수를 정의할 때는, def로 시작하거라. 다음에 함수의 이름을 정의하거라; 함수를 호출할 때는 그냥 그 이름을 호출(타자) 하거라." 매개변수는 정의와 어울립니다; 인자는 호출과 어울립니다. 길을 가로 막는 어떤 반환 유형이나 매개변수 유형 또는 참조와 값 매개변수도 전혀 없습니다. 그래서 이제 이전에 걸렸던 시간의 절반 이하로도 함수를 더 잘 이해할 수 있도록 가르칠 수 있습니다.
116 |
117 | 파이썬을 사용하자 우리의 컴퓨터 과학 프로그램은 모든 학생들에게 효율적이 되었습니다. 지난 이 년 동안 C++을 가르치면서 경험했던 것보다 일반적으로 더 높은 수준의 성공과 더 낮은 수준의 실패를 맛보고 있습니다. 더 빠르게 움직이고도 더 좋은 결과를 얻습니다. 강좌를 마칠 즈음이면 더욱 많은 학생들이 의미심장한 프로그램을 창조해 내는 능력을 익히고 이것을 이끌어 내는 프로그래밍을 경험합니다. 그리고 긍정적 태도를 가지고 강좌를 떠납니다.
118 |
119 |
120 |
공동체를 구축하기
121 |
122 |
123 | 이 책을 사용하여 프로그래밍을 배우고 가르치는 전세계의 모든 사람들이 전자우편을 보내 주셨습니다. 한 사용자 공동체가 탄생해야 했습니다. 많은 사람들이 http://www.thinkpython.com에 있는 동료 웹사이트에 재료들을 보내줌으로써 프로젝트에 공헌하였습니다.
124 |
125 | 그 책을 인쇄된 형태로 출간하면서 나는 사용자 공동체가 계속해서 더욱 빠르게 성장할 것이라고 예상합니다. 이 프로젝트에 임하면서 나는 이 사용자 공동체의 탄생과 교육자들 사이의 협동이 제시하는 가능성이 대단히 흥미로왔습니다. 함께 일함으로써 재료의 질을 향상시켜 우리의 목적에 이용할 수 있었고 귀중한 시간을 절약할 수 있었습니다. 여러분에게 우리의 공동체에 참여하기를 권합니다. 당신의 한 말씀을 고대합니다. feedback@thinkpython.com으로 저자들에게 전자우편을 보내 주십시오.
28 | "파이썬 요리책(The Python Cookbook)", 특히 앞의 몇 장을 읽어보자.
29 | 작성이 잘된 파이썬 코드의 예가 모인 훌륭한 소스이다.
30 |
31 |
32 | 문자열은 리스트로 구축하고 마지막에 ''.join을 사용하자.
33 | join 메쏘드는 리스트가 아니라 가름자(separator)에서 호출된다. 빈 문자열에서 호출되면 가름자 없이 조각들을 결합해 주는데, 이는 파이썬의 버릇으로서 처음 보면 약간 놀랍다.
34 |
35 | 중요한 것은 이것이다: +로 문자열을 구축하면 선형 시간이 아니라 제곱 시간이 걸린다! 관용구 하나를 배워야 한다면, 이 관용구를 익히자.
36 |
37 |
나쁨: for s in strings: result += s
38 | 옳음: result = ''.join(strings)
39 |
40 |
41 |
42 | 언제나 객체의 유형이 아니라 그의 능력을 사용하자. 파이썬은 동적으로 형이 정의되는 언어이다: 기본적으로 한 객체가 특정 유형인지 걱정하지 않아도 된다. 특정 인터페이스를 지원하기만 하면 된다. 이 때문에 인상적인 다형성을 무료로 사용할 수 있다. 예를 들어, 문자열이 알파벳인지 여부를 점검하는 코드는 다음과 같다:
43 |
44 |
for char in string:
45 | if char not in alphabet:
46 | raise ValueError, "Char %s not in alphabet %a" % (char, alphabet)
47 |
48 |
49 | alphabet이 문자열인지, 사전인지, 리스트인지, 아니면 내가 정의한 객체인지 문제가 되지 않는다. __contains__ 특수 메쏘드를 지원하기만 하면 된다.
50 |
51 |
52 |
53 |
54 | 가능하면 in을 사용하자
55 | (자신의 클래스에서 __contains__를 오버라이드하면 if x in y 구문을 지원할 수 있으며 __iter__를 오버라이드하여 for x in y 구문을 지원할 수 있다). 이 덕분에 서술문을 보편적이고 다형성 있게 유지할 수 있다.
56 |
57 |
개선: for key in d: print key # 임의의 문자열에도 작동한다
58 | 나쁨: for key in d.keys(): print key # 객체가 keys()를 가져야 하는 제한이 있다
59 | Better: if key not in d: d[key] = []
60 | Worse: if not dict.has_key(key): d[key] = []
61 |
62 |
63 | 주의: 사전을 수정하고 싶으면 여전히 d.keys()를 사용할 필요가 있다. for key in d: del d[key] 는 다음
64 | RuntimeError: dictionary changed size during iteration 에러를 야기한다. 대신에 for key in d.keys(): del d[key] 를 사용하자.
65 |
66 |
67 | 객체가 특정 유형이어야 한다면 강제형변환을 사용하자.
68 | x가 꼭 문자열이어야만 코드가 작동한다면, isinstance(str, x) 같은 것을 사용하는 대신에 str(x)을 사용하는 것이 어떨까? 에러를 잡고 싶다면, try/except에 싸 넣으면 되고, 모든 가능성을 예측하고 싶은 경우라면, 이것이 훨씬 더 일반적인 해결책이 될 것이다.
69 |
70 |
71 |
72 | if x == 0나 if x == "" 또는 if x == None나 if x == False 대신에 if not x을 사용하자; 마찬가지로, if x != 0나 if x != None 등등 대신에 if x을 사용하자. 예외의 경우가 있다면: 숫자에 대하여, 0은 거짓 값이므로, False를 돌려주는 것들과 0을 구별할 필요가 있다. 0으로 추정되는 부동 소수점 수와 int(0) 또는 float(0.0)를 비교할 때 주의하자: 반올림 에러 때문에 버그가 급격히 늘어날 수 있다.
73 |
74 |
75 | 문자열 모듈 말고 문자열 메쏘드를 사용하자.
76 | 예를 들어, startswith(s, 'abc') 대신에 s.startswith('abc')를 사용하자. 이렇게 하면 문자열 인터페이스의 일부만을 지원하는 다른 객체들을 사용할 수 있다 (예를 들어, 직접 작성한 것들): string 모듈 함수는 일반적으로 진짜 문자열을 예상한다. 몇몇 경우에는 import string을 사용할 필요가 있다: 예를 들어, maketrans는 여전히 문자열 모듈에서만 사용이 가능하다. 그렇지만, 일반적으로 저런 반입 서술문을 본다면 경고가 표시된다.
77 |
78 |
79 |
80 | for line in infile.readlines() 대신에, for line in infile을 사용하자.readlines와 xreadlines는 어쨌거나 파이썬 2.3에서부터 비추천이다. 새로운 반복자 프로토콜을 권장한다. for line in infile 버전을 사용하면 infile이 무엇이든 연속열 같이 행위하기만 하면 된다. 이는 검증에 아주 큰 도움이 될 수 있다. 실제로, 그냥 for line in lines을 사용하자: 기본적으로 줄이 파일에서 왔는지, 문자열 리스트에서 왔는지, 아니면 기타 다른 반복자인지, 사전의 키인지, 기타 무엇으로부터 왔든지 신경쓸 필요가 없다.
81 |
82 |
83 | 리스트를 역정렬하려면, 다음과 같이 하자:
84 |
85 |
list.sort()
86 | list.reverse()
87 |
88 |
89 | 훨씬 더 읽기 쉽고, 게다가 꼼수적인 1-줄 대안책보다 더 빠르다.
90 |
91 | 제-자리 메쏘드인 sort()와 reverse()는 값을 돌려주지 않으니 주의하자. 이 때문에 당황할 수 있는데, 왜냐하면 sorted_list = orig_list.sort()와 같이 해 보면 sorted_list는 None이고 이제 orig_list가 정렬되어 있기 때문이다. 그냥 역정렬된 리스트를 순회하고 싶을 뿐이라면 주의하자. (파이썬 2.5에서 부터) for i in reversed(sorted(orig_list))을 사용하면 된다.
92 |
93 |
94 |
95 | 무한 회돌이에는 'while 1:'을 사용하자. 즉, 회돌이 몸체를 적어도 한 번 실행하자.
96 | 이는 파이썬의 관용구이지만, 다른 사람들도 한 번쯤은 자신이 사용했던 언어에서 보았을 것이다. 예를 들어:
97 |
98 |
while 1:
99 | curr_line = reader.next()
100 | if not curr_line:
101 | break
102 | curr_line.process()
103 |
104 |
105 |
106 | 코드를 특수 사례로 어지럽히지 않기 위해 에러를 피하기 보다는 잡자. 이 관용구는 LBYL ('look before you leap(뛰기 전에 살펴보자)')에 대조하여 EAFP('easier to ask forgiveness than permission(허락보다 용서를 구하는 편이 더 쉽다)')라고 부른다. 이 덕분에 코드의 가독성이 더 좋아지는 경우가 많다. 예를 들어:
107 |
108 |
개악:
109 | # int 형변환이 에러를 일으킬지 점검한다
110 | if not isinstance(s, str) or not s.isdigit:
111 | return None
112 | elif len(s) > 10: # int 형변환에 너무 자리수가 많음
113 | return None
114 | else:
115 | return int(str)
116 |
117 | 개선:
118 | try:
119 | return int(str)
120 | except (TypeError, ValueError, OverflowError): # int 형변환 실패함
121 | return None
122 |
123 |
124 | (이 경우 주의할 것은 두 번째 버전이 더욱 더 좋은데
125 | , 선두의 +와 - 뿐만 아니라 (32-비트 머신의) 2와 10조 사이의 값도 올바르게 처리하기 때문이다. 가능한 모든 실패 사례를 예측하려고 코드를 어지럽히지 말자: 그냥 시도해 보고 적절하게 예외 처리를 하자.)
126 |
127 |
128 | 적절한 에러만 잡자.
129 | 어느 에러를 잡고 싶은지 지정하지 않고서 catch를 사용하는 것은 대단히 위험하다. 왜냐하면 아무거나 다 잡아 버리기 때문이다. ZeroDivisionError나 ValueError 같이, 특정한 종류의 에러가 예상된다면 그 에러만 일어날 거라는 가정하에 다른 어떤 것도 잡지 말자. 그렇지 않으면 메모리가 고갈될 수도 있으며, 또는 올바르지 못한 속성을 가진 또는 그 연산이 구현되지 않은 객체를 건넬 가능성이 있다. 이런 예측불가의 에러를 감춰버리면 디버깅이 아주 어려워진다. 특히 엉터리 에러 메시지를 인쇄한다면 말이다.
130 |
131 |
132 | 임시 변수를 사용하지 않고 값을 교환하기.
133 | 대신에, 묵시적인 터플 풀기를 사용하자. a, b = b, a를 사용하면 a와 b를 교환할 수 있다. 사실, 얼마든지 원하는 갯수만큼 이렇게 할 수 있다:
134 | a를 d, 등등에 짝지으려면 a, b, c, d = d, b, c, a.
135 |
136 |
137 |
138 | 리스트의 (또는 어떤 연속열이든지) 요소를 그의 인덱스로 얻으려면 zip을 사용하자:
139 |
140 |
indices = xrange(maxint) # 여기에서 한 번만 필요하다; 본인은 Utils.py에 정의해 두었다.
141 | for d, index in zip(data, indices):
142 | # 여기에서 d와 인덱스를 가지고 일을 한다
143 |
144 |
145 | (파이썬 2.3에서는 enumerate(data)를 지원하는데, 이 함수는 연속열을 게으르게 평가하며, 이 덕분에 이 관용구가 대체로 불필요하게 되었다. 그렇지만, 여러 리스트와 함께 인덱스를 포함시키고 싶을 경우에는 여전히 쓸모가 있다. 예를 들어, zip(list_1, list_2, indices)와 같이 말이다.
146 |
147 | 64-비트 시스템에서는 실패할 수도 있다.)
148 |
149 |
150 | 인덱스가 필요없다면, 그냥 다음과 같이 하자:
151 |
152 |
for i in items:
153 | something(i)
154 |
155 | ...다음은 추천하지 않는다:
156 |
157 | for index in range(len(items)):
158 | something(items[index])
159 |
171 | 언제나 윤곽잡기를 먼저 하고 나서 속도를 위한 최적화를 하자.
172 | 제일 먼저 가독성을 위한 최적화를 하자: '최적화된' 코드를 읽는 것보다 읽기 쉬운 코드를 조율하는게 더 쉽다. 특히 그 최적화가 효과적이지 못하다면 말이다. 코드를 읽기 힘들게 만드는 테크닉을 사용하기 전에, 내장 profile.py 스크립트로 어플리케이션을 실행하여 정말로 병목인지 점검해야 한다. 프로그램이 특정 메쏘드를 실행하는 데 실행시간의 10%를 소모한다면, 그의 속도를 10배나 증가시키더라도 총 실행시간의 9%를 절약할 뿐이다.
173 |
174 |
175 | 가능하면 항상 좋은 알고리즘을 사용하자.
176 | 위의 규칙이 적용되지 않는 경우는 대안 알고리즘들의 시간 복잡도에 큰 차이가 있을 경우이다. 제곱시간에서 선형시간으로, 또는 지수시간에서 폴리노미얼 시간으로 실행시간이 감소한다면 데이터 세트가 언제나 작을 것이라고 (20개 요소 이하라고) 확신하지 않는 한 언제나 시도해 볼 가치가 있다.
177 |
178 |
179 | 작동 할 만큼만 가장 단순하게 선택하자.
180 | 한 문자열이 특정한 하부문자열로 시작하는지 그저 알고 싶을 뿐이라면 정규 표현식을 사용하지 말자: 대신 .startswith을 사용하자. 그저 한 문자열에 특정 문자가 포함되어 있는지 알고 싶을 뿐이라면 .index를 사용하지 말자: 대신 in을 사용하자. 그냥 문자열 리스트를 사용해도 된다면 StringIO를 사용하지 말자. 일반적으로, 단순할 수록 버그가 줄어들고 코드는 더욱 읽기 쉬워진다. .index 호출을 복잡하게 조합할지라도 정규 표현식보다 훨씬 더 빠르며, 그 결과를 나포하는 것보다 그냥 일치시키는 편이 훨씬 이해하기 쉬울 것이다.
181 |
182 |
183 | 리스트로 문자열을 구축하고 끝에 ''.join을 사용하자.
184 | 물론, 이미 이를 위의 "파이썬 관용구"에서 보셨지만, 너무나 중요한 것이라서 다시 한 번 언급해야겠다고 생각했다.
185 | join은 문자열 메쏘드로서 리스트가 아니라 가름자(separator)에 요청된다. 이를 빈 문자열에서 호출하면 가름자 없이 조각들을 결합해주는데, 이는 파이썬의 버릇으로서 처음 보면 약간 놀랍다.
186 | 이것이 중요하다: +로 문자열을 구축하면 선형시간이 아니라 제곱 시간이 걸린다!
187 |
188 |
잘못:
189 | for s in strings: result += s
190 | 옳음:
191 | result = ''.join(strings)
192 |
193 |
194 |
195 | 가능하면 객체 신분에 대하여 테스트하자: 다시 말해 if x != None보다는 if x is not None이 더 좋다. 동등성보다 신분으로 객체를 테스트하는 것이 좀 더 효율적이다. 왜냐하면 신분은 실제 데이터가 아니라 메모리상의 주소만 점검하기 때문이다 (물리적 위치가 같은 객체이기만 하면 두 객체는 동일하다).
196 |
197 |
198 |
199 | 검색에는 리스트가 아니라 사전(또는 집합)을 사용하자.
200 | 두 리스트 사이에 공통 요소가 있는지 알아보려면, 첫 리스트를 사전에 넣고 그 안에서 두 번째 리스트 안의 원소들을 찾아 보자. 리스트에서 요소를 찾는 것은 선형-시간이지만, 반면에 사전이나 집합에서 요소를 찾는 것은 상수 시간이다. 이것으로 종종 검색 시간을 제곱 시간에서 선형 시간으로 줄일 수있다.
201 |
202 |
203 |
204 | 가능하면 내장 sort를 사용하자.
205 |
206 | sort는 맞춤 비교 함수를 매개변수로 취할 수 있지만, 이 때문에 아주 느릴 수 있는데 함수가 내부 회돌이에서 적어도 O(n log n) 시간 호출되어야 하기 때문이다. 시간을 절약하려면, 항목 리스트를 터플 리스트로 바꾸자. 여기에서 각 터플의 첫 요소는 각 항목에 대하여 그 함수로 미리 계산된 값이며 (예를 들어, 필드를 추출), 마지막 요소는 그 항목 자체이다.
207 |
208 | 이 관용구를 DSU('decorate-sort-undecorate')라고 부른다. 'decorate' 단계에서, (transformed_value, second_key, ... , original value)가 담긴 터플 리스트를 만든다. 'sort' 단계에서, 그 터플에 내장 sort를 사용하자.
209 | 'undecorate' 단계에서, 각 터플로부터 마지막 요소를 추출하여 원래 리스트를 정렬된 순서로 열람하자. 예를 들어:
210 |
211 |
aux_list = [i.Count, i.Name, ... i) for i in items]
212 | aux_list.sort() # Count로 정렬한 다음, Name으로 정렬, ... , 다음 요소 그 자체로 정렬한다
213 | sorted_list = [i[-1] for i in items] # 마지막 요소를 추출한다
214 |
215 |
216 | 최신 버전의 파이썬에서는 종종 DSU가 불필요하다.
217 | 다음 페이지에 파이썬에서의 다양한 정렬 테크닉에 관하여 연구가 잘 되어 있다.
218 |
219 |
220 | 함수를 리스트에 적용하려면 map과 filter를 사용하자.
221 | map은 함수를 리스트의 각 요소에 (기술적으로, 연속열에) 적용해서 그 결과를 리스트로 돌려준다. filter는 함수를 연속열의 각 요소에 적용해서, (__nonzero__ 내장 메쏘드를 사용하여) True로 평가된 요소들만을 모아서 리스트로 돌려준다. 이 함수들로 코드를 많이 줄일 수 있다. 또한 더 빠르게 만들 수 있는데, 회돌이가 전적으로 C API 안에서 일어나며 회돌이 변수를 파이썬 객체에 절대로 엮지 않기 때문이다.
222 |
223 |
개악:
224 | strings = []
225 | for d in data:
226 | strings.append(str(d))
227 |
228 | 개선:
229 | strings = map(str, data)
230 |
231 |
232 | 조건이 부가되어 있거나 함수가 메쏘드일 경우 리스트통합을 사용하자. 아니면 하나 이상의 매개변수를 취하자.
233 |
234 | 이런 사례에서는 map과 filter가 제대로 일을 하지 못하는데, 원하는 연산을 해주는 인자-한개짜리 함수를 새로 만들어야 하기 때문이다. 이 때문에 더욱 더 느려지는데, 파이썬 수준에서 더 많은 일이 수행되어야 하기 때문이다.
235 | 리스트 통합은 놀랍도록 읽기가 좋은 때가 많다.
236 |
237 |
개악:
238 | result = []
239 | for d in data:
240 | if d.Count > 4:
241 | result.append[3*d.Count]
242 |
243 | 개선:
244 | result = [3*d.Count for d in data if d.Count > 4]
245 |
246 |
247 | 똑같은 리스트 통합을 반복적으로 하고 있다면, 유틸리티 함수들을 만들어서 map이나 filter를 사용하자:
248 |
263 | 유틸리티 함수를 만들려면 함수 공장을 사용하자.
264 | 가끔, 특히 map과 filter를 아주 많이 사용하고 있다면, 다른 함수나 메쏘드가 단 한개의 매개변수를 취하도록 변환해주는 유틸리티 함수가 필요할 것이다. 특히나, 데이터를 그 함수에 한 번 묶고 난 다음, 다양한 객체들에다 반복적으로 적용하고 싶은 경우가 있을 것이다. 위의 예제에서는 한 객체의 특정 변수를 3배로 만들어주는 함수가 필요했다. 그러나 정말 필요한 것은 어떤 변수 이름이든 값을 돌려주고 그 가족에 곱셈 함수를 붙여주는 함수 공장이다:
265 |
277 | 이는 함수를 만들어내는 아주 강력하고 일반적인 테크닉이다. 예를 들어 지정된 필드에서 단어 리스트를 검색하거나, 한 특정 객체의 여러 필드에 여러 조치를 수행하는 등등의 테크닉에 사용된다. 매우 비슷한 일을 하는 자잘한 함수들을 수 없이 작성하는 일은 고통스럽다. 그러나 함수 공장으로 만들어내면 아주 쉬운 일이다.
278 |
279 |
280 |
281 | 합이나 곱 등등을 얻으려면 operator 모듈과 reduce를 사용하자.
282 | reduce는 함수 하나와 연속열 하나를 취한다. 먼저 그 함수를 첫 두 요소에 적용한 다음, 그 결과를 취하고 그 결과와 다음 요소에 그 함수를 적용하고, 또 그 결과를 취해서 그 결과와 다음 요소에 그 함수를 또 적용하고, 등등 리스트의 끝에 도달할 때까지 계속된다. 이 덕분에 리스트를 (또는 실제로 어떤 연속열도) 따라서 요소들을 축적하기가 아주 쉬워진다. 파이썬 2.3에는 (숫자 전용의) 내장 sum() 함수가 있음을 주의하자. 이 때문에 그 필요성이 예전만 못하다.
283 |
284 |
개악:
285 | sum = 0
286 | for d in data:
287 | sum += d
288 | product = 1
289 | for d in data:
290 | product *= d
291 |
292 | 개선:
293 | from operator import add, mul
294 | sum = reduce(add, data)
295 | product = reduce(mul, data)
296 |
297 |
298 |
299 | 필드를 이름에 짝지으려면 zip과 dict를 사용하자.
300 | zip은 한 쌍의 연속열을 터플 리스트로 바꿔준다. 안에는 각 연속열의 첫째값, 둘째값 등등의 값이 담긴다. 예를 들어, zip('abc', [1,2,3]) == [('a',1),('b',2),('c',3)]. 이를 이용하면 이름에 짝짓고 싶은 필드가 순서대로 되어 있을 때 타자수를 절감할 수 있다:
301 |
![[철학적 GNU 이미지]](./fdl/gnu-head-sm.jpg)
38 |
42 |