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는 importlib의 일부로 새로운 ‘ImportEngine’ 클래스를 도입하여 모듈 임포트와 관련된 모든 상태를 하나의 객체로 캡슐화할 것을 제안합니다. 이 객체의 새 인스턴스를 생성하면 __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()에 해당하는 import_module() 메서드가 포함됩니다 [3].

전역 임포트 상태에 대해 가정되고 유지되어야 하는 불변 조건이 있으므로, 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가 만드는 것과 비슷한, 별도의 컨텍스트 관리 객체를 사용할 가능성이 높습니다).

미해결 쟁점

전역 임포트 상태로 대체(fall back)하기 위한 API 설계

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

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

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

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

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

ImportEngine도 미리 채워진 모듈 캐시에서는 여전히 이러한 모듈을 반환합니다 - 문제가 되는 것은 오직 직접 로드하는 경우뿐입니다.

대체(substitution)의 범위

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

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

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