오랜 기간 파이썬의 선구자(Pythoneer) Tim Peters는 파이썬(Python)의 설계에 대해
BDFL들을 인도하는 20가지의 기본 원칙과 같은 교훈을 남겼다.
그 중 19개만 기록되었다.
*BDFL (Benevolent dictator for life) : 소수의 오픈소스 소프트웨어 개발 리더
==========
20가지의 기본 원칙(The Zen of Python)
못생긴 것보다 아름다운 것이 낫다. (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.)
네덜란드 사람이 아니면 처음에는 그런 방법이 분명하지 않을 수도 있지만요. ()
아무 것도 안 하는 것보다 지금 하는게 낫다. (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!)
Although that way may not be obvious at first unless you're Dutch.
==========
이스터에그(Easter Egg)
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!