PEP 406 – 임포트 상태의 캡슐화 개선

Author:: Alyssa Coghlan <ncoghlan at gmail.com>, Greg Slodkowicz <jergosh at gmail.com>
Status:: Withdrawn
Type:: Standards Track
Created:: 04-Jul-2011
Python-Version:: 3.4
Post-History:: 31-Jul-2011, 13-Nov-2011, 04-Dec-2011

Table of Contents

초록
PEP 철회
근거
제안
명세
미해결 문제
참조 구현
참고 문헌
Copyright

번역·라이선스 안내

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

초록

이 PEP는 모듈 임포트와 관련된 모든 상태를 하나의 객체로 캡슐화하는 새로운 ‘ImportEngine’ 클래스를 importlib의 일부로 도입할 것을 제안합니다. 그러면 이 객체의 새 인스턴스를 생성하는 것이 __import__() 함수를 재정의하여 import 문의 내장 구현을 완전히 대체하는 방식의 대안이 됩니다. 내장 임포트 기능과 임포트 엔진 객체를 통한 임포트를 함께 사용할 수 있도록, 이 PEP는 전역 임포트 상태를 일시적으로 대체하는 컨텍스트 관리 기반 접근 방식을 제안합니다.

이 PEP는 또한 GlobalImportEngine 서브클래스와, 프로세스 전역 상태에 “직접 기록(write through)”하는 이 클래스의 전역 접근 가능한 인스턴스를 포함할 것을 제안합니다. 이는 제안된 캡슐화 API와 기존 프로세스 전역 상태 사이에 하위 호환성을 갖춘 다리를 제공하며, 관련 상태 갱신(예: sys.path가 수정될 때 경로 캐시 항목을 선택적으로 무효화하는 것)을 간단하게 지원할 수 있게 합니다.

PEP 철회

이 PEP가 처음 작성된 이후 임포트 시스템은 Python 3.3의 PEP 420과 Python 3.4의 PEP 451의 일환으로 상당한 변화를 겪었습니다.

임포트 상태의 캡슐화를 제공하는 것은 여전히 매우 바람직하지만, 이는 PEP 451을 기반으로 삼고 PEP 451 호환 파인더와 로더의 사용만 허용하는 새 PEP에서 다루는 것이 더 낫습니다(이들은 이전 로더 API와 관련된, 전역 상태를 직접 조작하는 데서 오는 많은 문제를 피하기 때문입니다).

근거

현재 임포트 시스템과 관련된 상태 대부분은 sys 모듈의 모듈 수준 속성으로 저장됩니다. 유일한 예외는 임포트 잠금으로, 이는 직접 접근할 수 없고 imp 모듈의 관련 함수를 통해서만 접근할 수 있습니다. 현재 프로세스 전역 임포트 상태는 다음으로 구성됩니다.

sys.modules
sys.path
sys.path_hooks
sys.meta_path
sys.path_importer_cache
임포트 잠금 (imp.lock_held()/acquire_lock()/release_lock())

이 상태를 격리하면 하나의 프로세스 안에 여러 임포트 상태를 편리하게 저장할 수 있습니다. 임포트 기능을 독립된 객체에 두면 서브클래싱을 통해 추가 기능(예: 모듈 임포트 알림이나 어떤 모듈을 임포트할 수 있는지에 대한 세밀한 제어)을 더할 수도 있습니다. 또한 이 엔진을 서브클래싱하여 임포트 엔진 API로 기존 프로세스 전역 상태와 상호 작용할 수 있게 합니다.

네임스페이스 PEP들(특히 PEP 402)은 sys.path가 수정될 때 패키지 경로를 올바르게 갱신하기 위해 추가적인 프로세스 전역 상태가 필요할 수 있음을 제기합니다.

마지막으로, 이 모든 상태에 대해 일관된 객체를 제공하면 임포트 상태를 일시적으로 대체할 수 있게 하는 컨텍스트 관리 기능도 제공할 수 있게 됩니다.

제안

임포트 기능을 캡슐화하는 ImportEngine 클래스를 도입할 것을 제안합니다. 여기에는 필요할 때 내장 __import__() 대신 사용할 수 있는 __import__() 메서드와, importlib.import_module() [3]과 동등한 import_module() 메서드가 포함됩니다.

전제되고 유지되어야 하는 전역 임포트 상태 불변 조건이 있으므로, ImportEngine과 동일한 인터페이스를 가지되 현재 전역 임포트 상태에 직접 접근하는 GlobalImportState 클래스를 도입합니다. 이는 클래스 프로퍼티를 사용하여 쉽게 구현할 수 있습니다.

명세

ImportEngine API

제안하는 확장은 다음 객체들로 구성됩니다:

importlib.engine.ImportEngine

from_engine(self, other)

다른 ImportEngine 인스턴스로부터 새 임포트 객체를 생성합니다. 새 객체는 other에 있는 상태의 사본으로 초기화됩니다. importlib engine.sysengine에서 호출하면, from_engine()을 사용하여 전역 임포트 상태의 사본을 가진 ImportEngine 객체를 생성할 수 있습니다.

__import__(self, name, globals={}, locals={}, fromlist=[], level=0)

내장 __import__() 함수의 재구현입니다. 모듈 임포트는 전역 임포트 상태가 아니라 ImportEngine 인스턴스에 저장된 상태를 사용하여 진행됩니다. __import__ 기능에 대한 전체 문서는 [2]를 참조하십시오. ImportEngine 및 그 서브클래스의 __import__()는 __builtin__.__import__를 ImportEngine().__import__로 교체함으로써 import 문의 동작을 사용자 정의하는 데 사용할 수 있습니다.

import_module(name, package=None)

ImportEngine 인스턴스에 저장된 임포트 상태를 사용하는 importlib.import_module()의 재구현입니다. 전체 레퍼런스는 [3]을 참조하십시오.

modules, path, path_hooks, meta_path, path_importer_cache

프로세스 전역 sys 대응 항목들의 인스턴스별 버전입니다.

importlib.engine.GlobalImportEngine(ImportEngine)

전역 상태에 엔진과 같은 방식으로 접근할 수 있게 해 주는 편의 클래스입니다. ImportEngine처럼 __import__(), import_module(), from_engine() 메서드를 제공하지만, sys의 전역 상태에 직접 기록합니다.

다양한 네임스페이스 패키지 메커니즘을 지원하기 위해, sys.path가 변경될 때는 pkgutil.extend_path와 같은 도구를 사용하여 임포트 상태의 다른 부분(이 경우에는 패키지의 __path__ 속성)도 함께 수정해야 합니다. 또한 여러 가지 변경이 이루어질 때에는 경로 임포터 캐시도 무효화해야 합니다.

ImportEngine API는 관련된 임포트 상태 갱신을 단일 작업의 일부로 자동 수행하는 편의 메서드를 제공할 것입니다.

전역 변수

importlib.engine.sysengine

미리 생성된 GlobalImportEngine 인스턴스입니다. 선택적 engine 매개변수를 받도록 갱신된 임포터와 로더에서 사용하고, 프로세스 전역 임포트 상태의 사본으로 시작하기 위해 ImportEngine.from_engine(sysengine)과 함께 사용하도록 의도되었습니다.

파인더/로더 인터페이스 변경 없음

추가 상태를 받도록 PEP 302 API를 갱신하려고 시도하는 대신, 이 PEP는 ImportEngine이 콘텐츠 관리 프로토콜을 지원하도록 제안합니다(decimal 모듈의 컨텍스트 대체 메커니즘과 유사합니다).

ImportEngine의 컨텍스트 관리 메커니즘은 다음을 수행합니다:

진입 시: * 임포트 잠금을 획득합니다 * 전역 임포트 상태를 임포트 엔진 자체의 상태로 대체합니다
종료 시: * 이전의 전역 임포트 상태를 복원합니다 * 임포트 잠금을 해제합니다

이를 위한 정확한 API는 아직 정해지지 않았습니다(다만 decimal.localcontext가 생성하는 것과 유사한, 별도의 컨텍스트 관리 객체를 사용하게 될 가능성이 높습니다).

미해결 문제

전역 임포트 상태로 폴백하기 위한 API 설계

현재 제안은 전역 임포트 상태로 폴백하기 위해 from_engine() API에 의존합니다. 대신 전역 임포트 상태로 동적으로 폴백하는 변형을 제공하는 것이 바람직할 수도 있습니다.

그러나 “가능한 한 격리된” 설계로 시작하면 큰 장점이 하나 있습니다. 엔진 인스턴스 상태와 프로세스 전역 상태 사이의 경계를 다양한 방식으로 흐리는 서브클래스를 실험해 볼 수 있게 된다는 점입니다.

내장 모듈과 확장 모듈은 프로세스 전역이어야 합니다

플랫폼의 제약으로 인해, 각 내장 모듈과 확장 모듈은 프로세스마다 사본이 하나만 손쉽게 존재할 수 있습니다. 따라서 각 ImportEngine 인스턴스가 그러한 모듈을 독립적으로 로드하는 것은 불가능합니다.

가장 간단한 해결책은 ImportEngine이 그러한 모듈의 로드를 거부하고 ImportError를 발생시키는 것입니다. GlobalImportEngine은 그러한 모듈을 정상적으로 로드할 수 있을 것입니다.

ImportEngine은 미리 채워진 모듈 캐시에서는 여전히 그러한 모듈을 반환할 것입니다 - 문제를 일으키는 것은 그러한 모듈을 직접 로드하는 경우뿐입니다.

대체의 범위

앞의 미해결 쟁점과 관련하여, 컨텍스트 관리 API를 사용할 때 어떤 상태를 대체할 것인가 하는 문제가 있습니다. 현재는 캐시된 참조 때문에 sys.modules를 교체하는 방법을 신뢰할 수 없을 수 있으며, 근본적으로 일부 모듈은 플랫폼의 제약으로 인해 독립적인 사본을 갖는 것 자체가 불가능하다는 사실도 있습니다.

이 PEP의 일부로서, 다음 사항을 명시적으로 문서화할 필요가 있습니다:

전역 임포트 상태 중 어느 부분을 대체할 수 있는지 (그리고 대체되는 경우를 처리하지 않은 채 그 상태에 대한 참조를 캐시하는 코드는 버그가 있는 것으로 선언합니다)
어느 부분을 반드시 제자리에서 수정해야 하는지 (따라서 ImportEngine 컨텍스트 관리 API로 대체되지 않거나, 그 밖의 방식으로 ImportEngine 인스턴스 범위로 한정되지 않는 부분)