PEP 434 – 모든 브랜치에 적용되는 IDLE 개선 예외

Author:: Todd Rovito <rovitotv at gmail.com>, Terry Reedy <tjreedy at udel.edu>
BDFL-Delegate:: Alyssa Coghlan
Status:: Active
Type:: Informational
Created:: 16-Feb-2013
Post-History:: 16-Feb-2013, 03-Mar-2013, 21-Mar-2013, 30-Mar-2013
Resolution:: Python-Dev message

Table of Contents

초록
동기
근거
하위 호환성
참고 문헌
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

대부분의 CPython 트래커 이슈는 동작(behavior) 또는 개선(enhancement)으로 분류됩니다. 대부분의 동작 패치는 기존 버전용 브랜치에 백포트됩니다. 기능 개선 패치는 다음 Python 버전이 될 기본 브랜치에만 적용됩니다.

이 PEP는 …/Lib/idlelib/에 있는 IDLE 코드에 대해서는 개선 사항 적용 제한을 완화할 것을 제안합니다. 실제로 이는 IDLE 개발자가 패치를 분류하거나 그 분류에 합의할 필요 없이, IDLE 사용자와 향후 IDLE 개발에 무엇이 가장 좋은지에 집중할 수 있다는 뜻입니다. 또한 IDLE 패치를 반드시 ‘버그 수정’ 변경과 개선 변경으로 나눌 필요가 없다는 뜻이기도 합니다.

이 PEP는 기존 기능의 변경과 새 메뉴 항목이 필요한 정도의 작은 기능 추가에 적용되며, 테마 위젯이나 탭 방식 창(tabbed windows)으로 전환하는 것과 같은 대규모 재작성에는 반드시 적용되지는 않습니다.

동기

이 PEP는 오른쪽 클릭 컨텍스트 메뉴에 잘라내기, 복사, 붙여넣기를 추가하는 문제를 두고 트래커와 pydev 메일링 리스트 양쪽에서 벌어진 논쟁을 계기로 작성되었습니다(2005년에 열린 Issue 1207589 [1]; pydev 스레드 [2]). 이 기능들은 키보드 단축키로는 사용할 수 있었지만 컨텍스트 메뉴에는 없었습니다. 적어도 Windows에서는 해당되는 경우(읽기 전용 창에는 Copy만 있습니다) 이 기능들이 컨텍스트 메뉴에 있는 것이 표준이므로, 사용자는 잘라내거나 복사할 텍스트 또는 붙여넣을 슬라이스 지점을 선택한 후 키보드로 손을 옮길 필요가 없습니다. 컨텍스트 메뉴는 새 옵션이 추가되기 불과 10일 전까지도 문서화되어 있지 않았습니다(Issue 10405 [5]).

일반적으로 어떤 동작이 올바르다고 판단되는 문서와 충돌하면 버그라고 부릅니다. 그러나 문서가 없다면 무엇이 기준입니까? 코드 자체가 곧 문서라면, 트래커에 있는 대부분의 IDLE 이슈는 개선 이슈입니다. 합리적인 사용자 기대를 기준으로 삼는다면(물론 그것 자체도 의견 차이의 대상이 될 수 있습니다), 훨씬 더 많은 이슈가 동작 이슈가 됩니다.

컨텍스트 메뉴의 경우, 사람들은 이 추가 사항이 버그 수정인지 개선인지에 대해 의견이 갈렸습니다. 개선이라고 본 사람들조차도 패치를 백포트해야 하는지에 대해서는 의견이 달랐습니다. 이 PEP는 다른 표준 라이브러리 모듈보다 더 관대한 백포트를 명시적으로 허용함으로써 이러한 분류에 대한 의견 차이를 무의미하게 만들 것을 제안합니다.

Python에는 고급 기능이 많지만, Python은 초보자가 배우기 쉬운 컴퓨터 언어로 잘 알려져 있습니다 [3]. Python의 주요 철학 중 하나는 “배터리 포함(batteries included)”이며, 이는 다른 프로그래밍 언어에는 일반적으로 포함되지 않는 많은 모듈을 갖춘 Python 표준 라이브러리에서 가장 잘 드러납니다 [4]. IDLE은 초보자가 서드파티 IDE를 내려받아 설정하지 않고도 빠르게 시작할 수 있게 해 주므로 Python 도구 상자에서 중요한 “배터리”입니다. IDLE은 정규 교육 환경 안팎에서 Python을 교육용 언어로 사용하도록 장려하겠다는 Python 커뮤니티의 약속을 나타냅니다. 권장되는 교육 방식은 학습자가 IDLE로 시작하게 하는 것입니다. 이 PEP와 이 PEP를 통해 가능해질 작업은 IDLE을 초보자가 Python을 시작하기 위한 간단한 도구로 만들어, Python 커뮤니티가 학습자의 IDLE 경험을 훌륭하게 만들 수 있도록 해 줄 것입니다.

근거

사람들은 사실상 비공개인(문서화되지 않은) idlelib의 구현 모듈을 직접 임포트하기보다는, 주로 그래픽 사용자 인터페이스(GUI) 애플리케이션을 실행하여 IDLE을 사용합니다. 사용자가 셸을 사용하든, 편집기를 사용하든, 둘 다 사용하든, 하나의 Python 버전의 버그 수정 릴리스 내에서의 일관성보다 현재 Python 버전들의 최신 릴리스 전반에 걸친 일관성에서 더 큰 이점을 얻을 것이라고 저희는 믿습니다. 이는 기존 동작이 명백히 만족스럽지 않을 때 특히 그렇습니다.

사람들이 표준 인터프리터를 사용할 때, 운영 체제가 제공하는 창 틀은 모든 Python 버전에서 똑같이 동작합니다. 예를 들어 Microsoft가 명령 프롬프트 GUI를 업그레이드한다면, 그 안에서 어떤 Python이 실행되든 관계없이 개선 사항이 적용될 것입니다. 마찬가지로 편집기 X로 Python 코드를 편집한다면, 오른쪽 클릭 컨텍스트 메뉴나 찾기-바꾸기 상자 같은 동작은 편집 중인 Python의 버전은 물론 편집 중인 언어와도 무관합니다.

IDLE 개발자에게 돌아가는 이점은 엇갈립니다. 한편으로는 더 많은 버전을 테스트해야 하고, 특히 2.7에서는 패치를 조정해야 할 수도 있으므로 일이 늘어납니다. (물론 모든 것을 백포트하지는 않는 선택지도 있습니다. 이슈 12510의 경우, 클래스의 호출 팁(calltip)에 대한 일부 변경 사항은 구식 클래스(old-style class) 관련 문제 때문에 2.7 패치에 포함되지 않았습니다 [6].) 다른 한편으로는 사소한 문제를 둘러싼 논쟁(bike-shedding)이 기운을 소모시킬 수 있습니다. 버그에 대한 명백한 수정이 기능 개선처럼 보인다면, 버그 수정만 담은 별도의 패치를 작성하는 것은 더 많은 일이 됩니다. 또한 버전 간에 코드가 갈라지게 되면 향후 여러 버전에 걸친 패치가 더 어려워집니다.

이러한 문제는 찾아 바꾸기 대화 상자에서 잘 드러납니다. 이 대화 상자는 예전에 특정 사용자 입력에 대해 예외를 발생시켰습니다 [7]. 처리되지 않은 이 예외 때문에 IDLE이 종료되었습니다. 적어도 Windows에서는 이 종료가 조용히(트레이스백이 보이지 않은 채) 일어났으며, IDLE을 아이콘에서 평소처럼 시작한 경우에는 충돌처럼 보였습니다.

이것은 버그였습니까? IDLE 도움말(현재의 Help 하위 메뉴에 있음)에는 그저 “Replace… Open a search-and-replace dialog box”라고만 되어 있으며, 실제로 상자가 열리기는 했습니다. 일반적으로 라이브러리 메서드가 예외를 발생시키는 것은 버그가 아닙니다. 그리고 일반적으로 라이브러리 메서드가 자신이 호출하는 함수가 발생시킨 예외를 무시하는 것도 버그가 아닙니다. 따라서 상세한 문서가 없는 상황에서 ‘코드 = 문서’라는 철학을 채택한다면, ‘아니요’라고 답할 수도 있습니다.

하지만 IDLE이 종료될 필요가 없는데도 종료되는 것은 분명히 불쾌한 일입니다. 그래서 우리 중 네 명은 이를 막아야 한다는 데 동의했습니다. 그러나 그 대신 무엇을 해야 하는가라는 질문이 여전히 남아 있었습니다. 예외를 잡아야 합니까? 아예 예외를 발생시키지 않아야 합니까? 경고음을 내야 합니까? 오류 메시지 상자를 표시해야 합니까? 아니면 사용자의 입력으로 무언가 유용한 일을 시도해야 합니까? ‘크래시’를 유용한 동작으로 대체하는 것은 향후 Python 릴리스로 제한되는 기능 개선이겠습니까? IDLE 개발자가 그런 질문까지 해야 합니까?

하위 호환성

IDLE의 경우, 하위 호환성을 우려할 수 있는 사용자는 세 가지 유형이 있습니다. 첫째는 IDLE을 애플리케이션으로 실행하는 사람들입니다. 이들에 대해서는 이미 앞에서 논의했습니다.

두 번째는 idlelib 모듈 중 하나를 임포트하는 사람들입니다. 저희가 아는 한 이는 IDLE 애플리케이션을 시작하는 용도로만 사용되며, 저희는 그러한 사용 방식을 깨뜨리자고 제안하지 않습니다. 그 밖의 용도에서 이 모듈들은 문서화되어 있지 않으며 사실상 비공개 구현입니다. 어떤 IDLE 모듈이 공개로 정의되고, 문서화되고, 경우에 따라 tkinter 패키지로 옮겨진다면, 그때부터는 일반 규칙을 따르게 됩니다. (IDLE 코드를 작업하는 사람들을 위해 비공개 인터페이스를 문서화하는 것은 별개의 문제입니다.)

세 번째는 IDLE 확장을 작성하는 사람들입니다. 보장되는 확장 인터페이스는 idlelib/extension.txt에 나와 있습니다. 이 인터페이스는 적어도 기존 버전에서는 존중되어야 하며, 향후 버전에서도 가볍게 변경되어서는 안 됩니다. 그러나 “확장은 이 [EditorWindow] 인자에 대해 많은 것을 가정할 수 없습니다.”라는 경고가 있습니다. 이 보장이 패치에서 문제가 되는 경우는 드물 것이며, 이 문제는 ‘기능 개선’ 패치인지 ‘버그 수정’ 패치인지에 따라 달라지는 것도 아닙니다.

공교롭게도 컨텍스트 메뉴 패치가 적용된 후, 컨텍스트 메뉴에 항목을 추가하는 확장(드문 경우입니다)이 깨지게 된다는 점이 드러났습니다. 그 패치가 a) 표준 rmenu_specs에 새 항목을 추가했고 b) 모든 rmenu_spec이 길어질 것을 전제했기 때문입니다. 이것이 보장을 위반하는지는 분명하지 않지만, 전제 b)를 고치는 두 번째 패치가 있습니다. 이 패치는 첫 번째 패치를 되돌릴 필요가 없다는 것이 분명해졌을 때 적용해야 합니다.

참고 문헌

Copyright

This document has been placed in the public domain.