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 트래커 이슈는 동작 또는 개선으로 분류됩니다. 대부분의 동작 패치는 기존 버전용 브랜치로 백포트됩니다. 개선 패치는 다음 Python 버전이 되는 기본 브랜치로 제한됩니다.

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

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

동기

이 PEP는 오른쪽 클릭 컨텍스트 메뉴에 잘라내기, 복사, 붙여넣기를 추가하는 문제를 두고 트래커와 pydev 목록 모두에서 논쟁이 일어난 데서 비롯되었습니다 (2005년에 개설된 Issue 1207589 [1]; pydev 스레드 [2]). 해당 기능은 키보드 단축키로는 사용할 수 있었지만 컨텍스트 메뉴에는 없었습니다. 적어도 Windows에서는 해당 기능을 사용할 수 있을 때 메뉴에 표시하는 것이 표준이므로(읽기 전용 창에는 복사만 표시됨), 사용자는 잘라내거나 복사할 텍스트 또는 붙여넣을 슬라이스 지점을 선택한 후 키보드로 전환할 필요가 없습니다. 컨텍스트 메뉴는 새 옵션이 추가되기 10일 전까지 문서화되지 않았습니다 (Issue 10405 [5]).

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

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

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

근거

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

사람들이 표준 인터프리터를 사용할 때, OS가 제공하는 프레임은 모든 파이썬 버전에서 동일하게 동작합니다. 예를 들어, 마이크로소프트가 명령 프롬프트 GUI를 업그레이드한다면, 그 개선 사항은 그 안에서 어떤 파이썬이 실행되고 있든 상관없이 적용될 것입니다. 마찬가지로, 누군가 에디터 X로 파이썬 코드를 편집한다면, 우클릭 컨텍스트 메뉴나 검색-바꾸기 상자 같은 동작들은 편집 대상인 파이썬 버전에도, 심지어 편집 대상인 언어에도 좌우되지 않습니다.

IDLE 개발자들에게 있어 그 이득은 엇갈립니다. 한편으로는, 더 많은 버전을 테스트하고 특히 2.7의 경우 패치를 조정해야 할 수도 있다는 점에서 더 많은 작업이 필요합니다. (물론 모든 것을 백포트하지 않는다는 선택지도 있습니다. issue 12510의 경우, 클래스에 대한 calltip 변경 사항 일부는 구식(old-style) 클래스와 관련된 문제들 때문에 2.7 패치에 포함되지 않았습니다 [6].) 다른 한편으로는, 사소한 논쟁(bike-shedding)이 에너지를 소모시킬 수 있습니다. 버그에 대한 명백한 수정이 개선 사항처럼 보일 경우, 버그 수정만을 위한 별도 패치를 작성하는 것은 더 많은 작업이 됩니다. 그리고 버전 간 코드가 갈라지게 만드는 것은 향후 다중 버전 패치를 더 어렵게 만듭니다.

이러한 문제들은 검색-바꾸기 대화 상자를 통해 잘 드러납니다. 이 대화 상자는 특정 사용자 입력에 대해 예외를 일으키곤 했습니다 [7]. 잡히지 않은 이 예외는 IDLE을 종료시켰습니다. 적어도 윈도우에서는, 이 종료가 조용히(트레이스백이 보이지 않은 채) 일어났으며, IDLE을 아이콘에서 정상적으로 시작했다면 마치 충돌(crash)처럼 보였습니다.

이것은 버그였습니까? IDLE 도움말(현재 Help 서브메뉴에 있는)에는 단지 “Replace… Open a search-and-replace dialog box”(검색 및 바꾸기 대화 상자 열기)라고만 나와 있으며, 실제로 상자가 열리기는 했습니다. 일반적으로, 라이브러리 메서드가 예외를 일으키는 것 자체는 버그가 아닙니다. 그리고 일반적으로, 라이브러리 메서드가 자신이 호출한 함수에서 일어난 예외를 무시하는 것 역시 버그가 아닙니다. 그러므로 상세한 문서가 없는 상황에서 ‘코드가 곧 문서다’라는 철학을 채택한다면, ‘아니오’라고 답할 수도 있을 것입니다.

그러나 IDLE이 종료될 필요가 없는데도 종료되는 것은 분명히 거슬리는 일입니다. 그래서 저희 네 명은 이를 방지해야 한다는 데 동의했습니다. 하지만 대신 무엇을 해야 할지에 대한 문제는 여전히 남아 있었습니다. 예외를 잡아야 할까요? 그냥 예외를 일으키지 않아야 할까요? 삑 소리를 내야 할까요? 오류 메시지 상자를 표시해야 할까요? 아니면 사용자의 입력으로 유용한 무언가를 시도해야 할까요? ‘충돌’을 유용한 동작으로 대체하는 것이, 향후 파이썬 릴리스에 한정된 개선 사항이 될까요? 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.