좋은 파이썬 코드를 작성하기 위해선 그 철학을 이해해야 한다고 생각한다. PEP는 Python Enhancement Proposal의 약자로, 파이썬 개선 제안서를 의미하고 다양한 문서가 있다. 이 중에서 PEP20은 파이썬의 철학과 관련하여 다루고 있다.
PEP20 살펴보기
PEP20의 제목은 Zen of Python이며 젠 오브 파이썬, 파이썬의 도라고 불린다. 이것은 Tim Peters가 언급한, 파이썬의 철학을 담은 격언들을 모아놓은 것으로 파이썬스러운 코드를 작성하는 방법에 대한 지침을 제공한다.
이것은 python shell에서 다음의 명령어를 통해 확인할 수 있다.
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!파이썬의 철학에 대한 고찰
위의 격언들을 하나씩 뜯어보고 의미에 대해 고찰해보자.
-
Beautiful is better than ugly. 아름다운 것이 추한 것보다 낫다.
-> 코드는 읽기 쉽고 이해하기 쉬워야 한다. -
Explicit is better than implicit. 명시적인 것이 암시적인 것보다 낫다.
-> 코드에서 의도는 분명하게 드러내야 하며 추측을 요하지 않아야 한다. -
Simple is better than complex. 간결한 것이 복잡한 것보다 낫다.
-> 가능한 한 간단한 솔루션을 선택하며, 복잡성은 피해야 한다. -
Complex is better than complicated. 복잡한 것이 난해한 것보다 낫다.
-> 필요할 경우 복잡성을 받아들이되, 복잡한 코드는 이해하기 쉽도록 구성해야 한다. -
Flat is better than nested. 수평적인 구조가 수직적인 구조보다 낫다.
-> 코드의 구조는 가능한 평면적으로 유지하는 것이 좋으며, 중첩은 최소화해야 한다. -
Sparse is better than dense. 여유로운 것이 밀집한 것보다 낫다.
-> 코드는 공백을 적절히 사용하여 읽기 쉽게 작성해야 한다. -
Readability counts. 가독성은 중요하다.
-> 코드는 다른 사람이 쉽게 읽고 이해할 수 있어야 한다. -
Special cases aren't special enough to break the rules. 규칙을 깨야할 정도로 특별한 경우란 없다. Although practicality beats purity. 비록 실용성이 이상을 능가한다 하더라도.
-> 일관성이 중요하며, 규칙을 깨는 것은 지양해야 한다. 완벽을 추구하기보다는 실제 문제를 효과적으로 해결하는 것이 중요하다. -
Errors should never pass silently. 오류는 결코 조용히 지나가서는 안 된다. Unless explicitly silenced. 명시적으로 오류를 감추려는 의도가 아니라면.
-> 오류는 명확하게 처리되어야 하며, 무시되어서는 안 된다. 오류 처리는 의도적으로 이루어져야 하며, 무시는 그 자체로 명확한 의도가 필요하다. -
In the face of ambiguity, refuse the temptation to guess. 모호함을 피하라. 당신이 직면할지도 모를 유혹을 거부할 수 있을 정도로. There should be one-- and preferably only one --obvious way to do it. 명확한 것이 어떤 경우에는 명확하지 않을 수 있다. 하지만 그럼에도 불구하고 명확함을 추구해야 한다. Although that way may not be obvious at first unless you're Dutch. 비록 당신이 우둔해서 처음에는 명백해 보이지 않을 수도 있겠지만.
-> 코드 해석에 여지를 남기지 말고, 모호한 부분에 대해서는 추측하지 않아야 한다. 명확하지 하지 않은 상황에도 명확할 수 있도록 해야 한다. 올바른 접근법이 처음에는 명확하지 않을 수 있지만, 경험을 통해 배울 수 있다. -
Now is better than never. 이제는 해야 할 때다. Although never is often better than right now. 비록 하지않는 것이 지금 하는 것보다 나을 때도 있지만.
-> 완벽한 시점을 기다리기보다는, 지금 행동하는 것이 좋다. 즉흥적인 결정보다는 신중한 계획이 필요할 때도 있다. -
If the implementation is hard to explain, it's a bad idea. 설명하기 어려운 구현이라면 좋은 아이디어가 아니다. If the implementation is easy to explain, it may be a good idea. 쉽게 설명할 수 있는 구현이라면 좋은 아이디어일 수 있다. Namespaces are one honking great idea -- let's do more of those! 네임스페이스는 정말 대단한 아이디어다. -- 자주 사용하자!
-> 솔루션은 이해하기 쉬워야 하며, 복잡하게 설명이 필요한 솔루션은 좋지 않다. 코드를 조직화하고 관리하기 쉽게 만드는 네임스페이스는 매우 유용하며, 이를 적극적으로 활용해야 한다.
참고 자료
