파이썬의 선: pythonic함이란?

평화롭던 어느 날- 챗지피티한테서 미션을 받았다.

Zen of Python이라는 철학도 있어요. 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!

🧘‍♂️ The Zen of Python (파이썬의 선)

1. Beautiful is better than ugly.
   아름다운 것이 추한 것보다 낫다.
   → 코드 이쁘게 짜자.

2. Explicit is better than implicit.
   명시적인 것이 암시적인 것보다 낫다.
   → 뭘 하는지 드러나는 코드가 좋다.

3. Simple is better than complex.
   단순한 것이 복잡한 것보다 낫다.
   → 가능하면 간단하게 짜자.

4. Complex is better than complicated.
   복합적인 것이 복잡한 것보다 낫다.
   → 무슨뜻이지?
   • 복합적(complex): 긴 코드. 단어가 많은 코드
   • 복잡(complicated): 해석하기 어려운 코드. ‘난해’에 가까움.

   → 길더라도 가독성 좋은 코드를 짜자!

5. Flat is better than nested.
   평평한 구조가 중첩된 구조보다 낫다.
   → 너무 깊은 구조보단 단순한 계층이 좋다.

6. Sparse is better than dense.
   드문드문한 것이 빽빽한 것보다 낫다.
   
   • 드문드문함(sparse): 여백이 있고 흩뿌려진 코드
   • 빽빽함(dense) : 과도하게 모아진 코드.

   → 4번에서와 마찬가지로, 코드는 가독성이 중요하다는 의미~

7. Readability counts.
   가독성이 중요하다.
   → 내가 아니라 다른 사람도 읽을 수 있게 짜자!

8. Special cases aren’t special enough to break the rules. Although practicality beats purity.
   특수한 경우라도 규칙을 깨서는 안 된다. 하지만 그 규칙을 깰 정도로 실용적이라면 어쩔 수 없다.
   → 따로 처리될만한 예외는 최소화하되, 그래도 완벽함보단 일단 잘 돌아가는 게 우선이다.

9. Errors should never pass silently. Unless explicitly silenced.
   에러는 조용히 넘어가선 안 된다. 명시적으로 넘어가는 경우를 제외하고는.
   → 문제가 발생했을 때, 이미 예측했던 문제가 아니라면, 반드시 티가 나야 한다.

10. In the face of ambiguity, refuse the temptation to guess.
    애매하면 추측하지 마라.
    → 확실하지 않으면 멈추고 다시 생각하자!

11. 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.
    명백한 정답은 하나. 가능하면 딱 하나여야 한다. 물론 당신이 네덜란드인이 아닌 이상, 그 하나의 방법이 처음엔 잘 안 보일 수 있다.
    → 다양한 방법보단 명백한 하나가 좋다. 처음에는 안 보일지라도 익숙해지면 보일 것이다
    (파이썬의 창시자인 Guido van Rossum이 네덜란드 사람이라고 한다 ㅋㅋ)

12. Now is better than never. Although never is often better than right now.
    지금 하는 것이 안 하는 것보다 낫다. 하지만 ‘지금 당장’보다는 안 하는 게 나을 때도 있다.
    → 시도해보는 게 중요하다! 근데 급하게 하지는 말고(ㅋㅋ), 조금 더 고민해보고 팀원들과 소통하다보면 좀 더 최적의 아이디어가 등장할 수 있다.

13. 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.
    설명이 어려운 구현은 나쁜 아이디어다. 설명이 쉬운 구현은 좋은 아이디어일 수 있다.
    → 복잡하면 다시 생각해보자… 쉽게 설명되면 좋은 설계일 가능성이 높지만, 아닐 수도 있다!

14. Namespaces are one honking great idea – let’s do more of those!
    네임스페이스는 정말 끝내주는 개념이다 — 더 많이 쓰자!
    → 네임스페이스는 충돌을 막고 코드를 깔끔하게 해준다.
    • 네임스페이스?
      이름(name)을 어떤 객체(object)와 매핑할지에 대한 이야기. 파이썬에는 지역(local), 전역(global), 빌트인(built-in) 네임스페이스가 있다. 이름을 찾을 때는 지역 → 전역 → 빌트인 순으로 검색한다.
      • global 키워드를 사용하면 전역 네임스페이스에 변수를 선언할 수 있다.
      • nonlocal은 중첩 함수에서 가장 가까운 바깥쪽 지역 네임스페이스에 변수를 바인딩한다.

---

결론

파이썬의 선에서 알 수 있듯이, pythonic한 코드는 단순함을 추구하고, 가독성과 실용성을 최우선으로 여긴다.
나도 앞으로 ‘멋있어 보이는 코드’보다는 ‘잘 읽히는 코드’를 지향해야겠다.