[Active] PEP 434 - IDLE Enhancement Exception for All Branches

September 26, 2025

원문 링크: PEP 434 - IDLE Enhancement Exception for All Branches

상태: Active 유형: Informational 작성일: 16-Feb-2013

PEP 434 – 모든 브랜치에 대한 IDLE 향상 기능 예외

작성자: Todd Rovito, Terry Reedy
BDFL 위임자 (BDFL-Delegate): Alyssa Coghlan
상태: Active (활성)
유형: Informational (정보 제공)
생성일: 2013년 2월 16일
해결: Python-Dev message

개요 (Abstract)

대부분의 CPython 트래커 이슈는 동작(behavior) 또는 향상(enhancement)으로 분류됩니다. 대부분의 동작 관련 패치(behavior patches)는 기존 버전을 위한 브랜치(branch)로 백포트(backport)됩니다. 그러나 향상 관련 패치는 다음 Python 버전이 될 기본 브랜치(default branch)에만 적용되도록 제한됩니다.

이 PEP는 .../Lib/idlelib/에 있는 IDLE 코드에 대해 향상 기능 적용에 대한 제약을 완화할 것을 제안합니다. 실제로 이는 IDLE 개발자들이 패치를 분류하거나 분류에 동의할 필요 없이 IDLE 사용자 및 미래 IDLE 개발에 가장 좋은 것이 무엇인지에 집중할 수 있게 됩니다. 또한 IDLE 패치가 반드시 ‘버그 수정(bugfix)’ 변경과 ‘향상 기능(enhancement)’ 변경으로 나 뉠 필요가 없다는 것을 의미하기도 합니다.

이 PEP는 기존 기능의 변경 사항이나 새로운 메뉴 항목을 필요로 하는 작은 기능 추가에는 적용되지만, 테마 위젯으로 전환하거나 탭 형식 창(tabbed windows)으로 바꾸는 것과 같은 주요 재작성에는 반드시 적용되지는 않습니다.

동기 (Motivation)

이 PEP는 오른쪽 클릭 컨텍스트 메뉴에 잘라내기(Cut), 복사(Copy), 붙여넣기(Paste) 기능을 추가하는 것에 대한 트래커 및 pydev 메일링 리스트에서의 논란(Issue 1207589, pydev thread)으로 인해 촉발되었습니다. 이 기능들은 키보드 단축키로는 제공되었지만 컨텍스트 메뉴에는 없었습니다. 적어도 Windows에서는 해당하는 경우 (예: 읽기 전용 창에서는 복사만 가능) 컨텍스트 메뉴에 이 기능들이 포함되는 것이 표준이며, 사용자가 텍스트를 선택하거나 붙여넣기 지점을 선택한 후 키보드로 전환할 필요가 없도록 합니다. 이 컨텍스트 메뉴는 새로운 옵션이 추가되기 10일 전까지도 문서화되어 있지 않았습니다(Issue 10405).

일반적으로, 문서화된 내용과 충돌하는 동작은 버그(bug)로 간주됩니다. 그러나 문서가 없는 경우, 어떤 것이 표준이 될까요? 만약 코드가 자체적인 문서라고 한다면, 트래커에 있는 대부분의 IDLE 이슈는 향상 기능 이슈가 됩니다. 만약 합리적인 사용자 기대치(물론 이것 자체도 이견의 대상이 될 수 있습니다)를 기준으로 삼는다면, 훨씬 더 많은 이슈가 동작 이슈로 분류될 수 있습니다.

컨텍스트 메뉴의 경우, 기능 추가의 상태(버그 수정인지 향상 기능인지)에 대해 의견이 달랐습니다. 심지어 이를 향상 기능으로 본 사람들 사이에서도 패치를 백포트해야 하는지에 대해 의견이 달랐습니다. 이 PEP는 다른 표준 라이브러리(stdlib) 모듈보다 더 자유로운 백포팅을 명시적으로 허용함으로써, 이러한 상태 분류에 대한 이견을 무의미하게 만들 것을 제안합니다.

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

합리적 근거 (Rationale)

사람들은 주로 IDLElib 내부에 있는 사실상 비공개(undocumented) 구현 모듈을 직접 임포트하기보다는, 그래픽 사용자 인터페이스(GUI) 애플리케이션을 실행하여 IDLE을 사용합니다. 셸(shell)을 사용하든 에디터(editor)를 사용하든, 또는 둘 다 사용하든, 우리는 그들이 하나의 Python 버전에 대한 버그 수정 릴리스 내의 일관성보다는, 현재 Python 버전들의 최신 릴리스들 간의 일관성으로부터 더 많은 이점을 얻을 것이라고 믿습니다. 이는 기존 동작이 명확하게 만족스럽지 않을 때 특히 그렇습니다.

사람들이 표준 인터프리터를 사용할 때, OS가 제공하는 프레임워크는 모든 Python 버전에서 동일하게 작동합니다. 예를 들어, Microsoft가 Command Prompt GUI를 업그레이드한다면, 해당 개선 사항은 어떤 Python 버전이 그 안에서 실행되든 상관없이 나타날 것입니다. 마찬가지로, 편집기 X로 Python 코드를 편집할 경우, 오른쪽 클릭 컨텍스트 메뉴나 검색-교체 상자(search-replace box)와 같은 동작은 편집되는 Python 버전이나 심지어 편집되는 언어에도 의존하지 않습니다.

IDLE 개발자에게는 장단점이 있습니다. 한편으로는 더 많은 버전을 테스트하고, 특히 2.7 버전의 경우 패치를 조정해야 할 가능성이 있어 더 많은 작업이 필요합니다. (물론 모든 것을 백포트하지 않을 수도 있습니다. 이슈 12510의 경우, 클래스에 대한 calltip 변경 사항 중 일부는 old-style 클래스 문제로 인해 2.7 패치에 포함되지 않았습니다). 다른 한편으로는, 소모적인 논쟁(bike-shedding)은 에너지 소모가 큽니다. 버그에 대한 명백한 수정 사항이 향상 기능처럼 보인다면, 버그 수정 전용 패치를 별도로 작성하는 것은 더 많은 작업이 됩니다. 그리고 코드 베이스가 버전별로 달라지게 되면, 향후 여러 버전에 걸친 패치를 더 어렵게 만듭니다.

이러한 문제점은 검색 및 교체 대화 상자(search-and-replace dialog box)를 통해 잘 설명됩니다. 이전에는 특정 사용자 입력에 대해 예외(exception)를 발생시켰습니다. 이 처리되지 않은 예외로 인해 IDLE이 종료되었습니다. 적어도 Windows에서는 IDLE이 아이콘에서 정상적으로 시작되었을 경우, 종료가 조용히(추적 메시지 없이) 이루어져 충돌(crash)처럼 보였습니다.

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

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

하위 호환성 (Backwards Compatibility)

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

두 번째는 idlelib 모듈 중 하나를 임포트하는 사람들입니다. 우리가 아는 한, 이것은 IDLE 애플리케이션을 시작하기 위해서만 수행되며, 우리는 이러한 사용을 방해할 것을 제안하지 않습니다. 그렇지 않다면, 이 모듈들은 문서화되지 않았으며 사실상 비공개 구현(private implementations)입니다. 만약 IDLE 모듈이 공개되고, 문서화되고, 어쩌면 tkinter 패키지로 이동된다면, 그때는 일반적인 규칙을 따를 것입니다. (IDLE 코드 작업을 하는 사람들을 위한 비공개 인터페이스 문서화는 별개의 문제입니다.)

세 번째는 IDLE 확장 기능(extensions)을 작성하는 사람들입니다. 보장된 확장 인터페이스는 idlelib/extension.txt에 명시되어 있습니다. 이는 적어도 기존 버전에서는 존중되어야 하며, 미래 버전에서 경솔하게 변경되어서는 안 됩니다. 그러나 “확장 기능은 이 [EditorWindow] 인수에 대해 많이 가정할 수 없다”는 경고가 있습니다. 이 보장은 패치와 관련하여 거의 문제가 되지 않을 것이며, 이 문제는 ‘향상 기능’ 패치와 ‘버그 수정’ 패치에 특정한 것이 아닙니다.

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

참고 자료 (References)

IDLE: Right Click Context Menu, Foord, Michael. Cut/Copy/Paste items in IDLE right click context menu. Getting Started with Python. Batteries Included. IDLE breakpoint facility undocumented, Deily, Ned. IDLE: calltips mishandle raw strings and other examples, Reedy, Terry. IDLE: replace ending with ‘’ causes crash, Reedy, Terry.

이 문서는 퍼블릭 도메인(public domain)으로 지정되었습니다.

이 PEP 434는 IDLE의 개선 사항이 더 빠르게 사용자에게 도달하고, 개발자들이 버그 수정과 향상 기능 분류에 대한 소모적인 논쟁에서 벗어나 IDLE 사용자의 경험을 최적화하는 데 집중할 수 있도록 돕는 중요한 제안입니다.

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