엔지니어링 철학: Guido van Rossum, 가독성이 중요하다

핵심 요점
- 코드는 작성되는 것보다 훨씬 더 자주 읽힙니다. 그래서 van Rossum은 기계나 그 순간의 작성자가 아니라, 나중에 그 줄을 읽게 될 사람을 위해 Python을 최적화했습니다.
- 유의미한 공백은 읽기를 정직하게 만듭니다. 눈에 보이는 들여쓰기가 곧 실제로 실행되는 블록 구조이므로, Python 프로그램의 겉모습은 그것이 무엇을 하는지에 대해 거짓말을 할 수 없습니다.
- “명백한 방법이 하나 있어야 한다”는 것은, 낯선 사람이 쓴 코드도 한 사람의 손으로 쓴 것처럼 읽힌다는 뜻입니다. 하나의 관용구로 수렴하는 것은 미래의 모든 독자에게 주는 선물입니다.
- Python의 선(Zen)은 van Rossum이 아니라 Tim Peters의 것입니다. 흔히 잘못 알려진 부분입니다. Peters는 이미 언어 안에 녹아 있던 가치들을 정제해 낸 것입니다.
원칙
“Guido의 핵심 통찰 중 하나는 코드가 작성되는 것보다 훨씬 더 자주 읽힌다는 것이다.” – PEP 8, 이 통찰을 Guido van Rossum의 것으로 돌리며1
그 통찰은 언어 설계에서 가장 조용한 혁명적 주장이지만, 거의 모든 사람이 고개를 끄덕이고는 그냥 무시해 버립니다. 그 문장을 천천히 읽어 보세요. 코드는 작성되는 것보다 훨씬 더 자주 읽힌다. 한 번 타이핑한 줄은 수십 번 읽히게 됩니다. 그것을 승인하는 리뷰어, 그것을 확장하는 동료, 그것을 물려받는 낯선 사람, 그리고 가장 자주 읽는 사람은 6개월 뒤에 자신이 무슨 의도였는지 떠올리려 애쓰는 바로 당신입니다. 그것이 사실이라면, 소스 코드의 청중은 기계도 아니고 작성하는 순간의 작성자도 아닙니다. 나중에 그것을 읽는 사람입니다. 그리고 언어는 그 진짜 청중을 위해 최적화되어야 합니다.
거의 어떤 언어도 그렇지 않았습니다. 1980년대의 시스템 언어들은 컴파일러와 기계를 위해 최적화되었고, 스크립팅 언어들은 그 순간 작성자의 편의를 위해 최적화되었습니다. 그래서 그토록 많은 언어가 작성된 다음 날이면 읽을 수 없게 되어 버린 것입니다. Guido van Rossum의 베팅은 대신 독자를 위해 최적화할 수 있다는 것이었습니다. 명료함을 기본값으로 만들고 문법 자체로 강제한다면, 그것이 한 공동체 전체에 걸쳐 수십 년에 걸쳐 복리로 쌓이리라는 것이었습니다. 그는 거의 아무도 예측하지 못한 차이로 옳았습니다. Python의 선(Zen)은 모든 Python 프로그래머가 읽어 본 세 단어로 같은 가치를 정제합니다. “가독성이 중요하다(Readability counts).”2
그 신념은 감각은 기술적 시스템이다라는, 감각이 그저 주장하는 분위기가 아니라는 논증의 바탕에 깔린 바로 그 신념입니다. 가독성은 나중에 스타일 가이드로 덧붙이는 부드러운 취향이 아닙니다. Python에서 그것은 구조적입니다. 문법 안에 새겨져 있어서, 언어가 읽기 쉬운 버전만큼 쉽게는 읽을 수 없는 버전을 쓰게 내버려 두지 않습니다. van Rossum의 베팅은, 명료한 쪽을 가장 저항이 적은 길로 만들어 두면, 생태계 전체가 따로 지시받지 않아도 명료함 쪽으로 흘러가리라는 것이었습니다.
배경
Guido van Rossum은 1956년 1월 31일 네덜란드 헤이그에서 태어났고, 1982년 암스테르담 대학교에서 수학 및 컴퓨터과학 석사 학위를 받았습니다.3 그는 암스테르담에 있는 네덜란드 국립 수학·컴퓨터과학 연구소인 Centrum Wiskunde & Informatica (CWI)에서 일하기 시작했고, 그곳에서 그의 경력을 형성한 경험이 기다리고 있었습니다. 바로 ABC 프로그래밍 언어입니다.
ABC는 CWI에서 Leo Geurts, Lambert Meertens, Steven Pemberton이 설계한, 배우기 쉽고 읽기 쉽게 만들어진 교육용 언어였고, van Rossum은 1980년대 중반 몇 년간 그 구현에 매달렸습니다.4 ABC는 그가 이후에 한 모든 일에 메아리치는 두 가지 선택을 했습니다. 블록 구조를 표시하는 데 들여쓰기를 사용했고 – “오프사이드 규칙(off-side rule)”, 중괄호도 없고 begin/end도 없었습니다 – 가독성을 일차적인 설계 목표로 삼았으며, 프로그램은 대개 Pascal이나 C로 짠 동등한 코드의 4분의 1 크기였습니다.4 van Rossum은 그 들여쓰기 아이디어를 사랑하게 되었습니다. 그는 나중에, 들여쓰기가 중괄호를 어디에 둘 것인가에 대한 무의미한 종교 전쟁을 없애 주었다고 말했습니다.5 하지만 ABC에는 치명적인 결함도 있었습니다. 일체형(monolithic) 구현, 확장하기 어려운 폐쇄적인 설계, 그것을 진짜 Unix 프로그래머들에게서 멀어지게 한 학문적 폐쇄성. 그는 읽기 쉬운 언어를 직접 써 보았고 그 교훈의 양면을 모두 보았습니다. 어떤 아이디어가 진정으로 훌륭했는지, 그리고 어떤 것이 그 언어를 죽인 실수였는지를요.
그러고 나서 그 유명한 기원 이야기가 등장하는데, 그것은 정말로 전설이 말하는 그대로 일어났습니다. “6년도 더 전인 1989년 12월,” van Rossum은 이렇게 썼습니다. “나는 크리스마스 무렵 한 주 동안 나를 바쁘게 해 줄 ‘취미’ 프로그래밍 프로젝트를 찾고 있었다.”6 CWI에 있던 그의 사무실은 연휴 동안 닫혀 있었습니다. 그는 ABC의 가장 좋은 아이디어들 – 가독성과 들여쓰기 – 은 지키고 그 실수들은 고친 스크립팅 언어를 만들기 시작했는데, 이번에는 ABC가 끝내 닿지 못했던 Unix/C 해커들을 겨냥했습니다. 이름으로는, “약간 불경스러운 기분이었고 (그리고 Monty Python의 Flying Circus의 열렬한 팬이었기에)” 그는 Python을 골랐습니다.6 뱀이 아닙니다. 그 코미디 그룹입니다. 그는 1991년에 첫 버전을 공개적으로 발표했습니다.3

그가 한 일
가독성과 유의미한 공백
van Rossum이 ABC에서 가져온 가장 결정적인 설계 결정은, 입문자들은 논쟁하고 베테랑들은 더 이상 의식조차 하지 않는 그것입니다. 들여쓰기가 곧 문법이다. 대부분의 언어에서 블록 구조는 중괄호나 키워드로 표시되고, 들여쓰기는 그저 사람의 눈이 이용하고 컴파일러는 무시하는 장식일 뿐입니다. 그 말은 둘이 어긋날 수 있다는 뜻입니다. 중괄호는 한 가지를 말하는데 들여쓰기는 다른 것을 말할 수 있고, 코드는 한 가지를 하는 것처럼 보이면서 다른 것을 실행할 수 있습니다 – 들여쓰기가 오해를 부르는 고전적인 버그, Apple의 악명 높은 goto fail SSL 구멍을 낳은 부류의 실수입니다. 거기서는 잘못 끼어든 두 번째 들여쓴 줄이, 시각적으로는 그것을 품고 있는 것처럼 보이는 if 바깥에 놓여 있었습니다.
Python은 그 부류의 버그를 구조적으로 불가능하게 만듭니다. 눈에 보이는 들여쓰기가 곧 실행되는 블록 구조입니다. 그것이 어긋날 수 있는 두 번째 숨은 진실이란 없습니다. van Rossum이 이것을 ABC에서 물려받은 것은 그것이 중괄호 배치 논쟁을 없애 주었기 때문이지만, 더 깊은 보상은 정확히 그의 원칙입니다. 그것은 읽기를 정직하게 만듭니다. 독자의 눈이 프로그램의 형태로 지각하는 것이, 정의상, 인터프리터가 실행하는 형태입니다.45

정직한 구조는 또한 Python이 비프로그래머에게 그렇게 보이는 이유이기도 합니다. 마치 우연히 실행되는 구조화된 의사코드처럼요. 그것이 핵심이었습니다. van Rossum은 스스로를 매우 시각적인 사람이라고 말하는데, 표면은 다가가기 쉽게 구조는 눈에 보이게 설계해서, “코드를 읽는 것”과 “프로그램을 이해하는 것” 사이의 간극을 문법이 만들 수 있는 만큼 작게 했습니다.
Python의 선(Zen)과 “명백한 방법 하나”
1999년, 오랜 기간 핵심 개발자로 일한 Tim Peters는 Python에 생명을 불어넣은 설계 가치를 스무 개의 잠언으로 적어 내려갔습니다. 그것은 결국 PEP 20, Python의 선(Zen of Python)으로 모셔졌고, 언어 자체에 함께 실려 있습니다. Python 프롬프트에서 import this라고 입력하면 그것이 출력됩니다. 그 공로를 누구에게 돌리느냐는 중요한데 흔히 틀립니다. 그 글을 쓴 사람은 van Rossum이 아니라 Tim Peters입니다.2 하지만 그 선(Zen)은 Guido의 설계 감각을 정제한 것입니다 – Peters는 이미 언어 안에 들어 있던 가치들을, 좋은 비평가가 예술가의 의도를 예술가 자신보다 더 잘 표현해 내듯 그렇게 표현한 것입니다.
두 줄이 철학 전체를 짊어집니다. “가독성이 중요하다.” 그리고 “그것을 하는 명백한 방법이 하나 – 그리고 되도록이면 단 하나만 – 있어야 한다.”2 그 둘째 줄은 Perl의 유명한 좌우명, “그것을 하는 방법은 한 가지 이상 있다”의 의도적인 반전입니다. van Rossum의 Python은 반대 방향에 겁니다. 명백한 방법 하나를 제시하는 언어는, 누가 썼든 코드가 똑같아 보이는 언어이고, 그것은 누구나 다른 사람의 코드를 읽을 수 있다는 뜻입니다. 하나의 관용구로 수렴하는 것은 작성자에 대한 제약이 아닙니다. 그것은 미래의 모든 독자에게 주는 선물입니다. (그 잠언 자체의 구두점 – “그리고 되도록이면 단 하나만”을 감싼 엠 대시 – 마저도, 규칙을 진술하면서 그 규칙을 살짝 어기고 있다는 짓궂은 농담입니다.)
BDFL과 거버넌스: 2018년의 사임
Python의 생애 대부분 동안, van Rossum은 1995년 한 Python 모임에서 반쯤 농담으로 만들어지고 Barry Warsaw가 영구적인 것으로 굳힌 직함 아래에서 언어 설계에 대한 최종 결정권을 쥐고 있었습니다. BDFL, 자비로운 종신 독재자(Benevolent Dictator For Life)입니다.7 그것은 실제 거버넌스 모델이었습니다. 언어 변경은 PEP 절차 – Python Enhancement Proposals, 즉 어떤 변경이든 제안되고 토론되고 결정되는, 공개적이고 문서화되며 보관되는 메커니즘 – 를 거쳐 흘러갔지만, 합의가 실패하면 BDFL이 결정했습니다. 수십 년 동안 그것이 통한 까닭은, van Rossum의 감각이 바로 공동체가 신뢰하는 것이었기 때문입니다.
그것은 단 하나의 연산자를 두고 끝났습니다. PEP 572는 “바다코끼리(walrus)” 대입 표현식 :=을 도입했고, 그 논쟁은 유난히 험악했습니다 – van Rossum은 시끄럽고 끈질긴 반대를 무릅쓰고 그것을 밀어붙였습니다. 그것이 받아들여지고 며칠 뒤인 2018년 7월 12일, 그는 python-committers 메일링 리스트에 “권력 이양(Transfer of power)”이라는 제목의 이메일을 올렸습니다. “이제 PEP 572가 끝났으니,” 그는 이렇게 썼습니다. “나는 다시는 PEP 하나를 위해 그렇게 치열하게 싸우고서 그토록 많은 사람이 내 결정을 경멸하는 것을 보고 싶지 않다.” 그는 자신에게 “BDFL에서 영구 휴가”를 주었고 – 그리고 결정적인 부분으로 – 후임자를 지명하기를 단호히 거부하면서(“나는 후임자를 임명하지 않을 것이다”), 공동체가 스스로의 정부를 만들어 내도록 남겨 두었습니다.8 공동체는 그렇게 했습니다. 다섯 명으로 구성되어 선출되는 운영 위원회(Steering Council)가 PEP 8016으로 비준되어 이제 Python을 다스립니다. 자비로운 독재자가 의도적으로 그 독재를 폐지한 것입니다.
Python의 도달 범위
가독성에 건 베팅은 소프트웨어 역사상 가장 큰 결과 중 하나로 복리처럼 불어났습니다. Python은 사람들이 읽을 수 있는 언어였기 때문에 사람들이 가르칠 수 있는 언어가 되었습니다 – 이제 전 세계 대학에서 가장 지배적인 입문 언어입니다. 읽기 쉽고 확장 가능했기 때문에 과학 컴퓨팅의 접착제가 되었습니다. NumPy, SciPy, pandas, 데이터 과학 스택 전체가 그것입니다. 그리고 데이터 과학 스택이 이미 Python으로 되어 있었기 때문에, 딥러닝 혁명도 Python으로 지어졌습니다 – PyTorch, TensorFlow, JAX, 그리고 당신이 들어 본 거의 모든 모델이, 한 네덜란드 프로그래머가 크리스마스 휴가 동안 사람의 눈에 편하도록 설계한 언어로 구동됩니다. van Rossum 자신은 2020년에 은퇴에서 돌아와 Microsoft에 합류해 Faster CPython 프로젝트, 즉 인터프리터를 대략 두 배 빠르게 만들려는 노력에 참여했습니다 – 그의 표현대로, 자신의 뿌리로 돌아간 것입니다.9
그 방법
그 방법은 하나의 신념 – 독자를 위해 최적화하라 – 을 35년 동안 보기 드문 일관성으로 밀어붙인 것입니다.
코드를 읽는 사람을 위해 최적화하라. 기계가 아니라, 그 순간의 작성자가 아니라. 모든 표면적 결정 – 들여쓰기, 적은 키워드 어휘, 명료함에 대한 고집 – 은 나중에 그 줄을 읽게 될 사람을 위한 것입니다. 그 사람이 진짜 청중이고, 그런 사람이 훨씬 더 많기 때문입니다.1
구조를 눈에 보이게, 읽기를 정직하게 만들어라. 들여쓰기가 곧 블록 구조이므로, 눈이 지각하는 것이 인터프리터가 실행하는 것입니다. 언어는 코드의 겉모습과 그 동작이 어긋나는 것을 허락하지 않습니다.4
명백한 방법 하나를 선호하라. 같은 작업에 다섯 가지 관용구를 제공하려는 유혹에 저항하세요. 명료한 관용구 하나로 수렴한다는 것은, 낯선 사람이 쓴 코드도 한 사람의 손으로 쓴 것처럼 읽힌다는 뜻입니다.2
좋은 아이디어는 취하고 실수는 고쳐라. Python은 ABC의 가독성과 들여쓰기에서, ABC의 일체형이고 폐쇄적이며 확장 불가능한 설계를 뺀 것입니다. van Rossum은 무에서 발명하지 않았습니다. 그는 앞서 있던 것을 안목 있게 편집한 사람이었습니다.45
공개적으로 다스리되, 언제 놓아야 할지 알아라. PEP 절차는 설계 결정을 공개적이고 문서화된 것으로 만들었습니다. 그리고 자신이 최종 권위라는 사실이 공동체에 대한 봉사가 아니라 비용이 되었을 때, 그는 자신을 물러나게 했습니다 – 그리고 후임자를 세우기를 거부함으로써, 자신의 자리에 지속될 제도가 형성되도록 강제했습니다.8
영향의 사슬
그를 형성한 사람들
ABC, 그리고 CWI의 Lambert Meertens, Leo Geurts, Steven Pemberton. ABC는 van Rossum에게 그를 규정하는 두 가지 아이디어 – 문법으로서의 들여쓰기, 그리고 일차적 목표로서의 가독성 – 를 건네주었고, 실패함으로써 부정적인 교훈도 가르쳤습니다. 일체형을 짓지 말 것, 설계를 닫지 말 것, 일하는 프로그래머를 무시하지 말 것. Python은 구해 낸 ABC의 좋은 절반입니다. (직접적이고 형성적인 영향)
Modula-3. 그것의 깔끔한 모듈과 예외 설계는 Python 자체의 그것에 영향을 주었습니다. van Rossum이 모든 바퀴를 다시 발명하기보다 자신이 존경하는 언어에서 의도적으로 빌려 왔다는 것을 일깨워 줍니다. (직접적 영향)
C와 Unix 문화. C는 Python에 그 구현 언어(CPython은 C로 작성되었습니다)와 그 대상 청중 – ABC가 끝내 닿지 못한 Unix/C 해커들 – 을 주었습니다. Python은 C 위에 있는 읽기 쉬운 스크립팅 계층, C로 확장 가능하고, C 세계를 위한 접착제로 구상되었습니다. (형성적 영향)
그가 형성한 것들
지구상 가장 큰 프로그래밍 공동체. Python은 대부분의 척도에서 이제 세계에서 가장 널리 쓰이는 프로그래밍 언어이고, 초심자에게 가르치는 기본 첫 언어입니다. 한 세대가 읽히도록 설계된 문법 안에서 프로그램을 생각하는 법을 배웠습니다.
데이터 과학, AI, 그리고 과학 컴퓨팅. NumPy, pandas, PyTorch, TensorFlow – 현대 AI 시대 전체의 도구들이 Python 위에 놓여 있는데, Python이 연구자들이 읽고 확장할 수 있는 언어였기 때문입니다. 가독성에 건 베팅은, 간접적으로, 제가 일하는 분야를 떠받치고 있습니다.
오픈소스 거버넌스. BDFL 모델과, 선출된 운영 위원회로의 그 의도적인 해체는, 한 사람의 감각으로 이끌리던 프로젝트가 어떻게 그 사람의 권위보다 오래 살아남을 수 있는지에 대한 연구 대상 본보기가 되었습니다.
관통하는 흐름
Yukihiro Matsumoto는 프로그래머의 행복과 최소 놀람의 원칙을 위해 Ruby를 설계했고, van Rossum은 독자를 위해 Python을 설계했습니다. 그들은 두 위대한 “기쁨” 언어이고, 약간 다른 표적을 겨눈 같은 본능입니다 – Matz는 쓰는 느낌을 위해, van Rossum은 읽는 느낌을 위해 최적화합니다 – 그래서 둘은 그토록 자주 수렴하고, 그래서 두 공동체가 서로를 알아봅니다. Donald Knuth는 학계에서 문학적 프로그래밍(literate programming)으로 같은 목적지에 닿았습니다. 프로그램은 사람을 위해 쓰인 문학 작품이며, 기계가 그것을 실행할 수 있다는 것은 거의 부수적 효과라는 급진적인 주장입니다. van Rossum은 그 신념을 방법론이 아니라 언어의 문법 안에 새겨 넣었습니다. 그리고 Bjarne Stroustrup이 제로 오버헤드 성능을 맨 앞에 두고 C++가 유창하게 읽으려면 몇 년이 걸리는 언어로 자라게 내버려 둔 곳에서, van Rossum은 가독성을 맨 앞에 두고 그 대가로 인터프리터의 느림을 받아들였습니다 – 두 설계자, 정반대의 최우선순위, 각자 상대가 쓰기를 거부한 화폐로 값을 치렀습니다. (시리즈 연결)
내가 여기서 얻는 것
내가 간직하는 교훈은, 가독성이 예의가 아니라 실제 산출물이라는 것입니다. 코드는 작성되는 것보다 훨씬 더 자주 읽히므로, 읽기에 명료한 버전이 더 값진 버전입니다 – 그리고 “나중에 정리할게요”는 내가 지금 조용히 배신하고 있는 독자에 대한 약속입니다. van Rossum의 수는 명료한 버전을 기본값으로 만드는 것입니다. 그래서 옳은 일을 하는 것이 규율의 행위가 아니라 가장 저항이 적은 길이 되게 합니다. 그것은 품질이 유일한 변수다와 같은 기준입니다. 질문은 결코 “이게 실행되는가?”가 아니라 “이걸 다음에 읽는 사람이 필요한 만큼 빠르게 이해할 수 있을까?”입니다.
내가 지금 만들고 있는 세계에서 – 에이전트, 도구 루프, 프롬프트, 다른 에이전트와 미래의 내가 새벽 2시에 읽게 될 하네스 코드에서 – 유혹은 “가독성이 중요하다”의 정반대입니다. 영리한 한 줄짜리, 암묵적 상태, 아무도 머릿속에 담을 수 없는 코드베이스 여기저기 흩어진 같은 일을 하는 다섯 가지 방법. van Rossum의 수는 명백한 방법 하나를 골라 구조를 정직하게 만들어, 읽는 것이 곧 실행되는 것이 되게 하는 것입니다. 그 신념 – 명료함이, 의지력에 맡겨지는 대신 구조적으로 만들어지고 시스템의 문법으로 강제되면, 나중에 그것을 읽는 모든 사람에게 복리로 쌓인다는 신념 – 이 1989년 크리스마스 취미 프로젝트에서 2026년 에이전트 하네스까지 관통하는 흐름입니다. 독자가 청중입니다. 그들을 위해 만드세요.
FAQ
Guido van Rossum의 엔지니어링 철학은 무엇인가요?
van Rossum의 핵심 신념은 코드가 작성되는 것보다 훨씬 더 자주 읽히므로, 언어는 그것을 읽는 사람을 위해 최적화되어야 한다는 것입니다.1 그는 가독성을 일차적이고 구조적인 목표로 삼아 Python을 지었습니다 – 나중에 덧붙이는 스타일 지침이 아니라, 유의미한 들여쓰기, 적은 키워드 어휘, 그리고 “그것을 하는 명백한 방법이 하나 있어야 한다”는 원칙을 통해 문법 안에 새겨 넣었습니다.2 그는 여기에 더해 PEP 절차를 통해 언어를 공개적으로 다스렸고, 2018년에는 의도적으로 그 최종 권위 자리에서 물러났습니다.8
Python은 왜 중괄호 대신 들여쓰기를 사용하나요?
van Rossum은 1980년대에 CWI에서 작업한 ABC 언어에서 들여쓰기 기반 블록 구조(“오프사이드 규칙”)를 채택했습니다. 그는 그것이 중괄호를 어디에 둘 것인가에 대한 끝없는 논쟁을 끝내 준다는 점을 좋아했습니다.45 그것이 지속되는 더 깊은 이유는 읽기를 정직하게 만들기 때문입니다. 중괄호 언어에서는 들여쓰기가 장식적이라 중괄호와 어긋날 수 있고, 그래서 코드가 한 가지를 하는 것처럼 보이면서 다른 것을 실행할 수 있습니다(들여쓰기가 오해를 부르는 버그). Python에서는 눈에 보이는 들여쓰기가 곧 실행되는 블록 구조입니다 – 그것이 어긋날 수 있는 두 번째 숨은 진실이란 없습니다.
Python의 선(Zen)은 누가 썼나요?
오랜 기간 Python 핵심 개발자로 일한 Tim Peters가 Python의 선(Zen)을 썼습니다 – PEP 20으로 모셔지고 import this를 실행하면 출력되는 스무 개의 잠언입니다. 그것은 Guido van Rossum이 쓴 것이 아닙니다. 흔한 오해입니다.2 그것이 하는 일은 van Rossum 자신의 설계 가치를 기억하기 좋은 형태로 정제하는 것입니다 – “가독성이 중요하다”나 “그것을 하는 명백한 방법이 하나 – 그리고 되도록이면 단 하나만 – 있어야 한다” 같은 줄들이, 이미 언어 안에 새겨져 있던 감각을 표현해 냅니다.
Guido van Rossum은 왜 Python의 BDFL에서 물러났나요?
van Rossum은 수십 년 동안 Python을 그 BDFL – 자비로운 종신 독재자(Benevolent Dictator For Life) 로서 이끌었습니다. 1995년 한 Python 모임에서 반쯤 농담으로 만들어진 직함입니다.7 그는 격렬한 반대를 무릅쓰고 밀어붙인 PEP 572(바다코끼리 연산자 :=)가 논쟁 끝에 받아들여지고 며칠 뒤인 2018년 7월 12일에 사임했습니다. “권력 이양”이라는 제목의 이메일에서 그는 이렇게 썼습니다. “이제 PEP 572가 끝났으니, 나는 다시는 PEP 하나를 위해 그렇게 치열하게 싸우고서 그토록 많은 사람이 내 결정을 경멸하는 것을 보고 싶지 않다.” 그는 자신에게 “BDFL에서 영구 휴가”를 주었고, 후임자를 지명하기를 분명히 거부했습니다.8 공동체는 선출된 다섯 명의 운영 위원회로 그를 대체했습니다.
출처
-
“PEP 8 – Style Guide for Python Code,” peps.python.org, Guido van Rossum, Barry Warsaw, Alyssa Coghlan 작성. “Guido의 핵심 통찰 중 하나는 코드가 작성되는 것보다 훨씬 더 자주 읽힌다는 것이다.” 이 지침은 곧바로 PEP 20의 “가독성이 중요하다”를 인용합니다. ↩↩↩
-
Tim Peters, “PEP 20 – The Zen of Python,” peps.python.org. Tim Peters 작성(Guido van Rossum이 아님).
import this로 출력됨. “가독성이 중요하다.”와 “그것을 하는 명백한 방법이 하나 – 그리고 되도록이면 단 하나만 – 있어야 한다.”를 담고 있습니다. ↩↩↩↩↩↩ -
“Guido van Rossum,” Wikipedia. 1956년 1월 31일 네덜란드 헤이그 출생. 암스테르담 대학교 석사(1982). CWI에서 ABC 개발에 참여. 1989년 12월 Python 인터프리터 시작, 1991년 최초 공개. Monty Python의 Flying Circus에서 이름을 땄음. Google(2005–2012, Mondrian 코드 리뷰 도구를 만든 곳), Dropbox(2013–2019), Microsoft(2020년 11월부터). ↩↩
-
“ABC (programming language),” Wikipedia. CWI에서 Leo Geurts, Lambert Meertens, Steven Pemberton이 설계. 블록 구조에 들여쓰기(오프사이드 규칙)를 사용하는 교육/가독성 중심 언어. 프로그램은 동등한 Pascal이나 C의 대략 4분의 1 크기. van Rossum은 1980년대 중반 ABC 구현에 참여했고 그 들여쓰기와 가독성 아이디어를 Python으로 가져왔습니다. ↩↩↩↩↩↩
-
Bill Venners, “The Making of Python: A Conversation with Guido van Rossum,” Artima. Unix/C 해커들을 위해 ABC의 후예로 Python을 만든 것에 대한 van Rossum의 이야기 – ABC의 더 나은 속성(가독성, 그룹화를 위한 들여쓰기)은 지키면서 그 문제들은 고친 것, 그리고 들여쓰기가 중괄호 배치 논쟁을 끝냈기에 그것을 좋아하게 된 것에 대하여. ↩↩↩↩
-
Guido van Rossum, “Foreword for ‘Programming Python’ (1st ed.),” python.org. “6년도 더 전인 1989년 12월, 나는 크리스마스 무렵 한 주 동안 나를 바쁘게 해 줄 ‘취미’ 프로그래밍 프로젝트를 찾고 있었다.” 이름에 대하여: “나는 약간 불경스러운 기분이었기에 (그리고 Monty Python의 Flying Circus의 열렬한 팬이었기에) 프로젝트의 작업 제목으로 Python을 골랐다.” ↩↩
-
“Benevolent dictator for life,” Wikipedia. 이 용어는 1995년에 van Rossum에 대해 처음 쓰였습니다. Ken Manheimer가 한 Python 모임에서 “Benevolent Dictator”로 만들었고, Barry Warsaw가 “for Life”를 제안했습니다. Guido van Rossum, “Origin of BDFL,” Artima도 참조. 그 용어를 1995년 모임까지 거슬러 추적합니다. ↩↩
-
Guido van Rossum, “[python-committers] Transfer of power,” python-committers 메일링 리스트, 2018년 7월 12일. “이제 PEP 572가 끝났으니, 나는 다시는 PEP 하나를 위해 그렇게 치열하게 싸우고서 그토록 많은 사람이 내 결정을 경멸하는 것을 보고 싶지 않다.” 그는 “BDFL에서 영구 휴가를 나 자신에게 준다”고 발표하고 “나는 후임자를 임명하지 않을 것이다”라고 밝힙니다. 맥락: “Guido van Rossum resigns as Python leader,” LWN.net. PEP 572(바다코끼리 연산자)는 peps.python.org/pep-0572에 있습니다. ↩↩↩↩
-
“A Team at Microsoft is Helping Make Python Faster,” Microsoft for Python Developers Blog. van Rossum이 2020년에 그것을 위해 Microsoft에 합류한 Faster CPython 프로젝트에 대하여. 인터프리터를 대략 2배 빠르게 하는 것을 목표로 함. “Guido van Rossum’s Ambitious Plans for Improving Python Performance,” The New Stack도 참조. 은퇴에서 돌아온 것에 대한 van Rossum의 말: “나는 Microsoft에 지원해서 채용되었다… 나는 내 뿌리로 돌아가기로 했다.” ↩