파이썬의“PEP-302 새로운 수입 훅”경험

저는 Ruby (CRuby) 개발자 중 한 명입니다. 우리는 Ruby 2.0 릴리스 (2012/2 월 릴리스 예정)를 작업 중입니다.

Python에는 "PEP302 : 새로운 가져 오기 후크" (2003)가 있습니다.

이 PEP는 Python 가져 오기 메커니즘의 더 나은 사용자 정의를 제공하는 새로운 가져 오기 후크 세트를 추가하도록 제안합니다. 현재 가져 오기 후크 와는 달리 , 새로운 방식의 후크를 기존 구성표에 삽입하여 모듈을 찾는 방법과로드 방법을보다 세밀하게 제어 할 수 있습니다.

PEP302와 유사한 기능을 Ruby 2.0 (CRuby 2.0)에 도입하는 것을 고려하고 있습니다. Matz를 설득 할 수있는 제안을하고 싶습니다. 현재 CRuby는 표준 방식으로 파일 시스템에서만 스크립트를로드 할 수 있습니다.

PEP 302에 대한 경험이나 고려 사항이 있으면 공유하십시오.

예:

1. 훌륭한 사양입니다. 변경할 필요가 없습니다.
2. 거의 좋지만이 문제가 있습니다 ...
3. 2003으로 돌아 가면 사양을 다음과 같이 변경합니다.

저는 Python의 runpy 모듈의 관리자이며 현재 수입 시스템의 관리자 중 하나입니다. 수입 시스템은 매우 유연하지만, 약간의 조정 없이도 도매를 채택하지 않는 것이 좋습니다. 이전 버전과의 호환성 문제로 인해 필요 이상으로 어색한 것이 많습니다.

파이썬에서 PEP 302로 인해 한 가지 문제는 핵심 수입 시스템을 사용하는 데 얼마나 오래 걸렸는가입니다. 10 년 중 더 나은 기간 동안, 가져 오기 후크로 복잡한 작업을 수행하는 사람은 PEP 302 호환 로더 (예 : 우편 가져 오기)와 표준 파일 시스템 기반 가져 오기 메커니즘을 처리하는 두 가지를 구현해야합니다. 다가오는 3.3에서만 PEP 302 로더를 처리 할 때 표준 파일 시스템 가져 오기 메커니즘을 통해 가져온 모듈을 처리하게됩니다. 피할 수 있다면 그 실수를 반복하지 마십시오.

PEP 420 (Python 3.3 용으로 구현)은 프로토콜을 추가하여 수입자가 네임 스페이스 패키지에 부분을 제공 할 수 있도록합니다. 또한 Finder API 정의의 이름 지정 문제 (잘못된 이름의 "find_module"을보다 정확한 "find_loader"로 대체)를 수정합니다. 이것은 3.3rc1이 몇 주 안에 돌아가는 시간까지 언어 사양에 더 명확하게 문서화되어야합니다.

또 다른 주목할만한 문제는 PEP 302에 구체적으로 문서화 된 접근 방식이 너무 많은 프로세스 글로벌 상태를 가지고 있다는 것입니다. 그 길을 따라 가지 마십시오-좀 더 일관된 객체 모델로 상태를 캡슐화하여 다른 모듈을 선택적으로 가져 오기가 더 쉬워집니다 (C 확장 모듈은 그러한 캡슐화를 완전히 효과적이지만 일부 수준의 캡슐화조차도 방해합니다 도움이 될 수 있습니다).

PEP 406 (http://www.python.org/dev/peps/pep-0406/)은 개선 된 상태 캡슐화를 통해 파이썬 접근 방식의 역 호환 가능한 진화를 논의합니다. 처음부터 캡슐화 된 상태 모델이있는 경우 API를 적절하게 정의하고 임포터 및 로더가 전역 상태에 액세스하지 않도록 할 수 있습니다 (대신 활성 엔진에 대한 참조를 전달 함).

PEP 302에서 누락 된 또 다른 부분은 수입 업체가 해당 수입 업체가 제공 한 모듈에 대해 반복자를 요청할 수있는 기능입니다 (이는 동결 유틸리티 및 문서 문자열을 추출하는 자동 문서 유틸리티와 같은 경우에 필요함). : 그것은 매우 유용하기 때문에, 당신은 아마 가져 오기 이동에서 표준화 더 나을 것 http://docs.python.org/dev/library/pkgutil#pkgutil.iter_modules 우리는 아마 마침내 공식적으로 지정된이 상승합니다 ( Python 3.4의 API)

그리고 마지막 의견은 임포트 시스템과 로더 객체 사이의 책임 분담을 면밀히 검토해야한다는 것입니다. 특히 "load_module"API를 별도의 "init_module"및 "exec_module"단계로 분할하는 것이 좋습니다. 그러면 로더가 가져 오기 상태와 직접 상호 작용해야하는 정도를 최소화 할 수 있습니다.

PEP 302와 importlib는보다 유연한 수입 시스템의 출발점이지만 피해야 할 실수는 분명히 있습니다.

ncoghlan 옆에 나는 파이썬의 수입 시스템의 다른 관리자이자 현재 구현의 작성자 인 importlib (http://docs.python.org/dev/py3k/library/importlib.html)입니다. Nick이 동의 한 모든 내용이므로 추가 정보를 추가하고 싶습니다.

먼저, PEP 302에 너무 크게 의존하지 말고 importlib이 추상 기본 클래스 등의 측면에서 제공하는 것을 살펴보십시오. 하위 호환성을 위해 PEP 302와 호환 가능해야하지만 일부는 진정한 유연성에 대한 지원을 완성하기 위해 자체 API.

또 다른 중요한 점은 개발자에게 두 가지 유연성을 제공한다는 것입니다. 하나는 파일 시스템에 직접 파일 이외의 방식으로 개별 파일로 코드를 저장하는 기능 입니다 (가져 오기를 위해 스토리지 백엔드 라고 부릅니다 ). 예를 들어 코드가 zip 파일, sqlite 데이터베이스 등에 존재할 수 있습니다. 다른 지원은 Quixote (https://www.mems-exchange.org/software/quixote/)와 같은 방식으로 코드를 사전 처리 또는 사후 처리하도록 제어 할 수 있도록 허용하고 문자열 리터럴을 대체로 사용하는 것입니다. 변수를 지원하는 것이 훨씬 쉬울 것입니다.

후자는 거의 필요하지 않지만 전자는 지원에 대해 걱정해야하는 곳입니다. 그리고 여기에서 파일 시스템 상호 작용 API를 실질적으로 재정의하게됩니다. 일부 사람들은 코드와 함께 파일로 저장된 자산이 필요하기 때문에 파일을 읽고 파일을 검색하는 등 좋은 방법을 제공해야합니다. 사용 가능한 데이터 파일을 검색하고 나열하는 등의 작업을 위해 API의 일부를 구현해야합니다. .

그러나 코드 별 API도 필요합니다. Nick이 언급했듯이 파일 특정이 아닌 패키지에 포함 된 모듈 등을 발견하는 데 API가 필요합니다. 파일 개념을 추출한 모듈을 처리하기 위해 API를 사용하는 것에는 이러한 이중성이 존재하지만 결국 파일과 같은 자산 데이터에 액세스하기 위해 API를 제공해야합니다. 그리고 중복을 피하기 위해 다른 하나와 관련하여 하나를 구현하려고 시도하면 물이 실제로 어둡게됩니다 (즉, 사람들은 경로가 실제 경로가 아닐 수도 있다는 사실에주의를 기울이지 않고 예상되는 파일 경로 구조 등에 의존하게됩니다. 파일이 아닌 코드를 포함하는 zip 파일을위한 것이므로). IOW를 사용하면 두 개의 유사한 API를 구현해야하지만 장기적으로는 더 나아질 것입니다.

Nick이 말했듯이, 우리의 솔루션은 좋은 출발점이지만 API를 처음부터 디자인 할 때 오늘날의 방식은 아닙니다.

PEP 302를 사용하면 Python 가져 오기 메커니즘에 연결할 수 있습니다. 즉, 데이터베이스, zip 파일 등과 같은 다른 소스에서 코드를 가져올 수 있습니다.

파이썬의 임포트 구현에는 파이썬 임포트의 도입으로 곧 단순화 될 복잡한 역사가 있습니다.

코너 케이스에 대해 길고 열심히 생각하는 것이 좋습니다. 그러면 유용한 구현을 얻을 수 있습니다.