Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 264 – 시뮬레이션된 셸에서의 future 문

Author:
Michael Hudson <mwh at python.net>
Status:
Final
Type:
Standards Track
Requires:
236
Created:
30-Jul-2001
Python-Version:
2.2
Post-History:
30-Jul-2001

Table of Contents

번역·라이선스 안내

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

초록

PEP 236에서 언급했듯이, “시뮬레이션된 대화형 셸”이 “실제” 대화형 셸에서의 __future__ 문 동작을 흉내 낼 명확한 방법이 없습니다. 즉, __future__ 문의 효과가 셸이 살아 있는 동안 계속 유지되도록 할 방법이 없습니다.

이 PEP는 또한 이 기회에 PEP 236에서 언급된 또 하나의 미해결 문제를 정리합니다. 이는 compile()을 호출하는 코드에 영향을 주는 future 문의 효과를 compile()이 상속하지 않도록 막을 수 없다는 문제입니다.

이 PEP는 첫 번째 문제를 해결하기 위해 내장 함수 “compile”에 선택적인 네 번째 인자를 추가하고, __future__.py에 정의된 _Feature 인스턴스에 정보를 추가하며, 표준 라이브러리 모듈 “codeop”과 “code”에 그러한 셸을 쉽게 만들 수 있도록 하는 장치를 추가할 것을 제안합니다.

두 번째 문제는 compile()에 또 하나의 선택적 인자를 추가하는 것만으로 해결합니다. 이 인자가 0이 아니면 future 문의 효과를 상속하지 않습니다.

명세

내장 “compile” 함수에 네 번째 선택적 인자인 “플래그(flags)” 인자를 추가할 것을 제안합니다. 이 인자를 생략하면 Python 2.1의 동작과 달라지는 점이 없습니다.

이 인자가 주어지면 정수여야 하며, 이 정수는 가능한 여러 컴파일 시점 옵션을 비트필드로 나타냅니다. 이 비트필드는 Python 인터프리터의 C 부분에서 future 문을 가리키는 데 이미 사용하고 있는 CO_* 플래그와 같은 값을 가집니다.

compile()은 주어진 플래그에 설정된 비트 중 인식하지 못하는 것이 있으면 ValueError 예외를 발생시켜야 합니다.

주어진 플래그는 어차피 설정되었을 플래그와 비트 단위 “or” 연산으로 결합됩니다. 단, 새로 추가되는 다섯 번째 선택적 인자가 0이 아닌 정수이면 주어진 플래그가 그대로 사용되는 플래그 집합이 됩니다.

위에서 언급한 플래그는 현재 Python에 노출되어 있지 않습니다. __future__.py의 _Feature 객체에 필요한 비트를 담은 .compiler_flag 속성을 추가하여 다음과 같은 코드를 작성할 수 있도록 할 것을 제안합니다.:

import __future__
def compile_generator(func_def):
    return compile(func_def, "<input>", "suite",
                __future__.generators.compiler_flag)

최근의 변경으로 이 같은 비트를 사용하여 코드 객체가 특정 기능을 켠 채로 컴파일되었는지 알 수 있게 되었습니다. 예를 들어 다음 값은

codeob.co_flags & __future__.generators.compiler_flag``

코드 객체 “codeob”이 제너레이터가 허용된 환경에서 컴파일된 경우에만 0이 아닌 값이 됩니다.

또한 __future__ 모듈에 .all_feature_flags 속성을 추가하여, 실행 중인 인터프리터가 지원하는 모든 __future__ 옵션을 손쉽게 열거하는 방법을 제공하겠습니다.

또한 표준 라이브러리 모듈 codeop에 클래스 두 개를 추가할 것을 제안합니다.

그중 하나인 Compile은 __call__ 메서드를 갖춥니다. 이 메서드는 2.1의 내장 “compile”과 거의 같이 동작합니다. 다른 점은 __future__ 문을 컴파일한 뒤에는 이를 “기억”하여 이후의 모든 코드를 해당 __future__ 옵션이 적용된 상태로 컴파일한다는 것입니다.

이는 위에서 언급한 __future__ 모듈의 새 기능을 사용하여 이루어집니다.

codeop에 추가되는 다른 클래스인 CommandCompiler의 객체는 기존 codeop.compile_command 함수의 역할을 하되, __future__를 인식하는 방식으로 수행합니다.

마지막으로, 표준 라이브러리 모듈 code의 InteractiveInterpreter 클래스가 CommandCompiler를 사용하도록 수정하여 기본 Python 셸의 동작을 한층 더 가깝게 흉내 내도록 할 것을 제안합니다.

하위 호환성

영향은 거의 없거나 전혀 없을 것입니다. compile에 대한 변경은 기존 코드에 아무런 차이를 만들지 않으며, codeop에 새 함수나 클래스를 추가하는 것도 마찬가지입니다. code.InteractiveInterpreter를 사용하는 기존 코드는 동작이 바뀔 수 있습니다. 하지만 “실제” Python 셸을 더 잘 흉내 내게 되므로 더 나은 방향으로만 바뀝니다.

상위 호환성

__future__ 기능을 추가할 때 Lib/__future__.py에 해야 하는 손질은 조금 더 복잡해질 것입니다. 그 밖의 모든 것은 그대로 잘 동작할 것입니다.

문제점

위 인터페이스를 Jython에서 구현하는 데 큰 지장이 없기를 바랍니다.

구현

일련의 예비 구현은 [1]에 있습니다.

Tim Peters가 가볍게 손질한 뒤, 이제 체크인되었습니다.

참고 문헌