[Rejected] PEP 666 - Reject Foolish Indentation

원문 링크: PEP 666 - Reject Foolish Indentation

상태: Rejected 유형: Standards Track 작성일: 03-Dec-2001

PEP 666 – 어리석은 들여쓰기 거부 (Reject Foolish Indentation)

  • 작성자: Laura Creighton
  • 상태: Rejected (거부됨)
  • 유형: Standards Track
  • 생성일: 2001년 12월 3일
  • Python 버전: 2.2
  • 게시 이력: 2001년 12월 5일

초록 (Abstract)

모든 Python 개발자는 탭(tabs)과 공백(spaces)을 혼용하는 것이 좋지 않다는 점에 동의합니다. 일부 개발자들은 이보다 더 나아가 특정한 들여쓰기 방식만을 고집하곤 합니다. 이 PEP는 개발자들이 자신이 원하는 Python의 동작 방식을 정의할 수 있도록 하여, 자신이 선호하는 방식으로만 프로그램이 실행되고 그렇지 않은 방식으로는 실행되지 않도록 하는 것을 제안합니다. 이는 커맨드 라인 스위치를 통해 구현될 것입니다. 프로그래머가 원하는 방식으로 포맷되지 않은 프로그램은 IndentationError를 발생시키게 됩니다.

구체적인 제안은 다음과 같습니다:

  • python -TNone: 탭이 하나라도 있으면 실행을 거부합니다.
  • python -Tn: 탭이 정확히 n개의 공백이 아닐 경우 실행을 거부합니다.
  • python -TOnly: 블록이 탭이 아닌 다른 것으로 들여쓰기 된 경우 실행을 거부합니다.

탭과 공백을 혼용하는 사람들은 당연히 자신들의 프로그램이 실행되지 않는다는 것을 알게 될 것입니다. 아쉽게도, 이들에게 원격으로 전기 충격을 줄 방법을 찾지는 못했습니다. (하지만 누군가 이 방법을 찾아낸다면, 이 옵션을 PEP에 추가하게 되어 기쁠 것입니다.)

도입 배경 (Rationale)

python-list@python.org (일명 comp.lang.python) 메일링 리스트는 주기적으로 탭과 공백에 대한 논쟁으로 들끓습니다. Python에서 들여쓰기가 문법적으로 중요하다는 점을 고려할 때, 이는 피할 수 없는 현상입니다. 이러한 논쟁은 문제 해결에 전혀 도움이 되지 않으며, 단지 여러 사람들을 좌절시키고 화나게 할 뿐입니다. 결국 서로에게 무례한 말을 하기 시작하며 이는 모두에게 슬픈 일입니다. 또한, Python으로 무언가를 만드는 데 사용할 수 있는 귀중한 시간을 낭비하고 있다는 점도 슬픕니다. 더욱이, Python 커뮤니티 전체의 대외적인 측면에서 볼 때, 이는 상당히 불행한 일입니다. 탭과 공백에 대해 게시물을 올리지 않는 사람들은 (놀랍게도) 눈에 띄지 않지만, 게시물을 올리는 사람들은 나머지 우리를 다소 어리석게 보이게 만듭니다.

문제는 ‘당신과 나의 귀중한 시간을 낭비하지 마세요’라고 정중하게 말할 방법이 없다는 것입니다. 이미 격렬한 논쟁(flame war) 한가운데 있는 사람들은 당신이 그들을 동정하여 행동한다고 믿으려 하지 않으며, 자신들의 시간이 자신들 마음대로 쓸 수 있는 시간이라고 당연히 주장합니다. 이들은 이 비참한 논쟁에 끈적한 당밀에 갇힌 파리처럼 갇혀 있으며, 스스로 벗어날 수 없다는 것은 자명합니다. 벗어날 수 있었다면 이미 그렇게 했을 것입니다.

하지만 오늘 저는 ‘n’ 키가 들러붙어 키보드를 청소하는 데 시간을 보내야 했습니다. 그래서 이 사람들에게 연민을 느끼는 것 외에도 상당히 짜증이 납니다. 이 PEP를 작성하면, Guido에게 신속하게 거부해달라고 요청할 수 있을 것이라고 생각합니다. 그러면 다음에 이 논쟁이 다시 시작될 때, 우리는 ‘Guido는 탭을 싫어하는 사람들이나 탭만 쓰는 사람들에게 맞춰서 상황을 바꾸지 않을 것이므로, 이 대화는 시간 낭비입니다’라고 말할 수 있습니다. 그러면 모든 사람들은 조용히 다음을 믿을 수 있습니다. a) 자신이 옳고, b) 다른 사람들은 바보이며, c) 바보들과 연구실을 공유할 필요가 없다는 것이 부인할 수 없는 행운이라는 점입니다. (이는 논쟁하는 사람들이 _지금_도 할 수 있는 일이지만, 분명히 잊어버린 것 같습니다.)

그리고 python-list는 새로 온 사람들에게 너무 적대적인지 여부보다는, 너무 잘난 척하는지에 대해 다시 걱정할 수 있게 될 것입니다. 아마도 누군가는 Python 2.2의 Non-Classic 클래스에서 __getattr__과 __getattribute__의 차이점이 무엇인지 저에게 설명해 줄 수 있을 것입니다. 이것은 제가 현재 탭 관련 스레드 한가운데에 어리석게 게시한 질문입니다. 저는 그 질문에 대한 답을 알고 싶습니다.

이 제안이 받아들여진다면, 아마도 누군가에게 엄청난 양의 작업이 필요할 것입니다. 그러나 저는 이 제안이 받아들여지기를 원하지 않으므로 신경 쓰지 않습니다.

참고 자료 (References)

Tim Peters가 이미 (개인 서신으로) 답변해주었습니다. 제 초기 2.2 버전에는 __getattribute__가 없었고, __getattr__은 현재의 __getattribute__처럼 구현되었습니다. 이는 수정되었습니다. 중요한 결론은 제 데코레이터 패턴(Decorator Pattern)이 안전하며 세상이 평화롭다는 것입니다.

이 문서는 퍼블릭 도메인(public domain)에 있습니다. 최종 수정: 2025년 2월 1일 08:55:40 GMT

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments