__future__ — 미래의 문법 정의
future — 미래의 문법 정의 (Future statement definitions)
from __future__ import feature 형태의 임포트를 future statement라고 불러요. Python 컴파일러가 이 문장을 특별하게 처리해서, 해당 기능이 정식으로 표준이 되기 전에도 그 기능을 쓸 수 있게 해 주죠.
출처: Python 표준 라이브러리
본문
from __future__ import feature 형태의 임포트를 future statement라고 불러요. Python 컴파일러가 이 문장을 특별 처리해서, 새 기능이 정식 표준이 되는 릴리스 이전에도 그 기능을 쓸 수 있게 해 줘요.
여기서 재미있는 점이 있어요. future statement는 컴파일러가 특별한 의미를 부여하지만, 실제로는 다른 import 문처럼 그대로 실행돼요. __future__ 모듈도 다른 일반 모듈과 똑같이 import 시스템이 처리해요. 이런 설계는 세 가지 목적이 있어요.
- 기존에 import 문을 분석하는 도구들이 헷갈리지 않게 해요. 그 도구들은 자기들이 import하는 모듈을 그대로 찾을 수 있길 기대하니까요.
- 호환성이 깨지는 변경이 언제 도입됐고, 언제 의무화됐는지(혹은 될지)를 문서화해요.
__future__를 import해서 내용을 들여다보면 프로그래밍 방식으로도 확인할 수 있는, 말 그대로 '실행 가능한 문서'죠. - Python 2.1 이전 릴리스에서는 future statement가 적어도 런타임 예외를 내도록 보장해요. 2.1 이전에는
__future__라는 모듈 자체가 없었으니 import가 실패하거든요.
모듈 내용 (Module Contents)
__future__에서 어떤 기능 설명도 삭제되지 않아요. Python 2.1에서 도입된 이후 이 메커니즘으로 언어에 들어온 기능들을 정리하면 이래요.
__future__.nested_scopes— optional in 2.1.0b1, mandatory in 2.2 — PEP 227: Statically Nested Scopes__future__.generators— optional in 2.2.0a1, mandatory in 2.3 — PEP 255: Simple Generators__future__.division— optional in 2.2.0a2, mandatory in 3.0 — PEP 238: Changing the Division Operator__future__.absolute_import— optional in 2.5.0a1, mandatory in 3.0 — PEP 328: Imports: Multi-Line and Absolute/Relative__future__.with_statement— optional in 2.5.0a1, mandatory in 2.6 — PEP 343: The "with" Statement__future__.print_function— optional in 2.6.0a2, mandatory in 3.0 — PEP 3105: Make print a function__future__.unicode_literals— optional in 2.6.0a2, mandatory in 3.0 — PEP 3112: Bytes literals in Python 3000__future__.generator_stop— optional in 3.5.0b1, mandatory in 3.7 — PEP 479: StopIteration handling inside generators__future__.annotations— optional in 3.7.0b1, mandatory in Never [1] — PEP 563: Postponed evaluation of annotations, PEP 649: Deferred evaluation of annotations using descriptors
class __future__._Feature
__future__.py 안의 각 문장은 이런 형태를 가져요.
FeatureName = _Feature(OptionalRelease, MandatoryRelease,
CompilerFlag)
보통 OptionalRelease는 MandatoryRelease보다 작고, 둘 다 sys.version_info와 같은 형태의 5-튜플이에요.
(PY_MAJOR_VERSION, # the 2 in 2.1.0a3; an int
PY_MINOR_VERSION, # the 1; an int
PY_MICRO_VERSION, # the 0; an int
PY_RELEASE_LEVEL, # "alpha", "beta", "candidate" or "final"; string
PY_RELEASE_SERIAL # the 3; an int
)
_Feature.getOptionalRelease()
OptionalRelease는 그 기능이 처음 받아들여진 릴리스를 기록해요.
_Feature.getMandatoryRelease()
아직 안 일어난 MandatoryRelease의 경우, 이 값은 그 기능이 언어의 일부가 될 릴리스를 예측해요.
반면 이미 일어난 경우엔 그 기능이 언어의 일부가 된 시점을 기록해요. 그 시점 이후의 릴리스에서는 future statement 없이도 해당 기능을 쓸 수 있고, 그런 import를 계속 써도 괜찮아요.
MandatoryRelease는 None일 수도 있는데, 계획된 기능이 취소됐거나 아직 결정되지 않았음을 뜻해요.
_Feature.compiler_flag
CompilerFlag는 (비트필드) 플래그로, 동적으로 컴파일되는 코드에서 그 기능을 켜기 위해 내장 함수 compile()의 네 번째 인자로 넘겨야 하는 값이에요. 이 플래그는 _Feature 인스턴스의 _Feature.compiler_flag 속성에 저장돼요.
더 알아보기
- Future statements — 컴파일러가 future import를 어떻게 처리하는지에 대한 설명.
- PEP 236 - Back to the future —
__future__메커니즘의 원래 제안서.