__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)

보통 OptionalReleaseMandatoryRelease보다 작고, 둘 다 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를 계속 써도 괜찮아요.

MandatoryReleaseNone일 수도 있는데, 계획된 기능이 취소됐거나 아직 결정되지 않았음을 뜻해요.

_Feature.compiler_flag

CompilerFlag는 (비트필드) 플래그로, 동적으로 컴파일되는 코드에서 그 기능을 켜기 위해 내장 함수 compile()의 네 번째 인자로 넘겨야 하는 값이에요. 이 플래그는 _Feature 인스턴스의 _Feature.compiler_flag 속성에 저장돼요.

더 알아보기

  • Future statements — 컴파일러가 future import를 어떻게 처리하는지에 대한 설명.
  • PEP 236 - Back to the future__future__ 메커니즘의 원래 제안서.