[Final] PEP 421 - Adding sys.implementation

원문 링크: PEP 421 - Adding sys.implementation

상태: Final 유형: Standards Track 작성일: 26-Apr-2012

PEP 421 – sys.implementation 추가

개요

이 PEP (Python Enhancement Proposal)는 sys 모듈에 새로운 속성인 sys.implementation을 도입합니다. 이 속성은 현재 실행 중인 인터프리터 구현에 대한 통합된 정보를 담고 있습니다. 따라서 sys.implementation은 표준 라이브러리가 구현별 정보를 찾아볼 수 있는 원천이 됩니다.

이 PEP의 제안은 대체 Python 구현(alternate implementations)에 Python이 더욱 친화적이 되도록 하는 광범위한 노력과 일치합니다. 여기서는 새로운 변수와 그 변수가 포함해야 하는 제약 조건을 설명합니다. 또한, sys.implementation의 즉각적인 사용 사례 몇 가지도 설명합니다.

동기 (Motivation)

수년 동안 “Python이라는 언어”와 “CPython (참조 구현)” 간의 구분이 점점 더 중요해지고 있습니다. 이러한 변화의 대부분은 Jython, IronPython, PyPy와 같은 실용적인 대체 Python 구현들의 등장 때문입니다.

그러나 거의 20년 동안 CPython 중심의 Python (즉, 대부분의 Python 역사)을 생각해 보십시오. 이러한 CPython 중심의 접근 방식은 표준 라이브러리와 인터프리터 내부에 CPython에 특화된 수많은 요소들을 발생시키는 데 기여했습니다. 최근 몇 년 동안 핵심 개발자들이 이 문제를 해결하기 위해 노력했지만, 여전히 많은 CPython 특화 요소들이 남아있습니다.

이 PEP는 해결책의 일부를 제시합니다: 구현별 세부 사항을 통합하기 위한 단일 네임스페이스입니다. 이는 구현별 세부 사항을 언어에서 분리하려는 노력을 집중시키는 데 도움이 될 것입니다. 또한, 다중 구현 사고방식(multiple-implementation mindset)을 육성할 것입니다.

제안 (Proposal)

우리는 sys 모듈에 sys.implementation이라는 새로운 속성을 추가할 것입니다. 이 속성은 (매핑이 아닌) 속성 접근 방식(attribute-access)을 가진 객체로, 구현별 정보를 포함합니다.

이 객체의 속성들은 인터프리터 실행 중 및 구현 버전 내내 고정된 상태를 유지합니다. 이는 sys.implementation의 속성에 의존하는 동작이 버전 간에 변경되지 않도록 보장합니다.

이 객체는 아래 “필수 속성 (Required Attributes)” 섹션에 설명된 각 속성을 가집니다. 이러한 속성 이름은 밑줄로 시작하지 않습니다. 표준 라이브러리와 언어 정의는 이러한 필수 속성에만 의존할 것입니다.

이 제안은 소수의 속성만 요구하는 보수적인 접근 방식을 취합니다. 더 많은 속성이 적절하다고 판단되면, “새로운 필수 속성 추가 (Adding New Required Attributes)”에 설명된 대로 신중하게 추가될 수 있습니다.

이 PEP는 sys.implementation에 다른 제약 조건을 두지 않지만, 여기에 설명된 기능 외의 기능에 의존하지 않을 것을 권장합니다. 이 권장 사항의 유일한 예외는 밑줄로 시작하는 속성입니다. 구현자들은 해당 속성을 구현별 데이터를 저장하는 데 적절하게 사용할 수 있습니다.

필수 속성 (Required Attributes)

다음은 표준 라이브러리 및 언어 정의가 의존할 sys.implementation의 속성으로, 구현자(implementers)는 이를 정의해야 합니다.

  • name: 구현을 나타내는 소문자 식별자입니다. 예시로는 'pypy', 'jython', 'ironpython', 'cpython' 등이 있습니다.
  • version: 구현된 언어의 버전이 아닌, 구현 자체의 버전입니다. 이 값은 “버전 형식 (Version Format)”에 설명된 형식을 따릅니다.
  • hexversion: sys.hexversion과 동일한 16진수 형식의 구현 버전입니다.
  • cache_tag: PEP 3147 캐시 태그에 사용되는 문자열입니다. 일반적으로 이름과 버전의 조합이 됩니다 (예: CPython 3.3의 경우 'cpython-33'). 그러나 구현은 명시적으로 다른 캐시 태그를 사용할 수 있습니다. cache_tag가 None으로 설정되면 모듈 캐싱을 비활성화해야 함을 나타냅니다.

새로운 필수 속성 추가 (Adding New Required Attributes)

시간이 지남에 따라 sys.implementation에 더 많은 필수 속성이 추가될 것입니다. 그러나 각 속성은 모든 Python 구현에서 의미 있는 사용 사례가 있어야만 고려될 수 있습니다. 이는 표준 라이브러리 또는 언어 사양의 사용 사례를 통해 가장 명확하게 드러납니다.

새로운 필수 속성에 대한 모든 제안은 일반적인 PEP 프로세스를 거칠 것입니다. 이러한 PEP는 길 필요는 없지만 충분히 길어야 합니다. 새로운 속성의 근거, 사용 사례 및 다양한 Python 구현에 미칠 영향을 충분히 설명해야 합니다.

버전 형식 (Version Format)

sys.implementation의 주요 목적 중 하나는 표준 라이브러리 내부에서 사용될 정보를 포함하는 것입니다. version 속성의 유용성을 높이기 위해, 그 값은 구현 전반에 걸쳐 일관된 형식이어야 합니다.

따라서 sys.implementation.version의 형식은 sys.version_info의 형식을 따를 것이며, 이는 사실상 named tuple입니다. 이는 익숙한 형식이며 일반적인 버전 형식 규칙과 대체로 일치합니다.

근거 (Rationale)

구현별 정보의 현재 상태는 해당 정보를 더욱 취약하고 유지보수하기 어려운 방식으로 제공합니다. platform.python_implementation()에서 볼 수 있듯이, 정보가 여러 모듈에 흩어져 있거나 다른 정보에서 추론됩니다.

이 PEP는 그 접근 방식에 대한 주요 대안입니다. 구현별 정보를 단일 네임스페이스로 통합하고, 암묵적이었던 것을 명시적으로 만듭니다.

타입 고려사항 (Type Considerations)

sys.implementation의 타입에 대한 논의에 쉽게 빠져들 수 있습니다. 그러나 그 목적은 표준 라이브러리와 언어 정의를 지원하는 것입니다. 따라서 일반적으로 더 많이 사용되는 기능과 달리, 그 타입에 관해 정말 중요한 것은 많지 않습니다. 따라서 불변성(immutability) 및 시퀀스 여부(sequence-ness)와 같은 특성은 고려되지 않았습니다.

유일한 실제 선택은 속성 접근(attribute access)을 가진 객체와 항목 접근(item access)을 가진 매핑(mapping) 사이였습니다. 이 PEP는 네임스페이스의 비교적 고정된 특성을 반영하기 위해 점(dotted) 접근 방식을 지지합니다.

비필수 속성 (Non-Required Attributes)

이 PEP의 초기 버전에는 비필수적인 구현별 데이터를 담는 metadata라는 필수 속성이 포함되어 있었습니다. 그러나 sys.implementation의 목적을 고려할 때, 이는 불필요한 추가임이 입증되었습니다.

궁극적으로, 비필수 속성은 이 PEP에서 사실상 무시됩니다. 부주의한 사용이 미래의 필수 속성과 충돌할 수 있다는 것 외에는 어떠한 영향도 미치지 않습니다. 그러나 이는 sys.implementation에 대한 미미한 우려일 뿐입니다.

왜 sys의 일부인가? (Why a Part of sys ?)

sys 모듈은 인터프리터 중심 변수와 함수를 보관하는 저장소이므로, 새로운 네임스페이스는 sys 모듈에 포함됩니다. 많은 구현별 속성들이 이미 sys에 있습니다.

값에 대한 엄격한 제약이 필요한 이유 (Why Strict Constraints on Any of the Values?)

“버전 형식 (Version Format)”에서 이미 언급했듯이, sys.implementation의 값은 표준 라이브러리에서 사용하기 위한 것입니다. 이러한 값에 제약을 가하고, 본질적으로 그에 대한 API를 지정함으로써, 구현 방식과 관계없이 일관되게 사용될 수 있습니다. 그러나 제약을 과도하게 지정하지 않도록 주의해야 합니다.

논의 (Discussion)

sys.implementation에 대한 주제는 2009년 python-ideas 목록에 처음 제기되었으며, 대체로 긍정적인 반응을 얻었습니다. 필자는 최근 pure-Python imp.get_tag() 작업을 하면서 이 논의를 다시 시작했습니다. 논의는 계속 진행 중입니다. 이슈 #14673의 메시지들도 관련이 있습니다.

최근 논의의 상당 부분은 sys.implementation에 사용할 유형에 집중되었습니다.

사용 사례 (Use-cases)

platform.python_implementation()

“명시적인 것이 암묵적인 것보다 낫다 (explicit is better than implicit)”

platform 모듈은 여러 sys 변수에서 단서를 찾아 Python 구현을 결정합니다. 그러나 이 접근 방식은 구현이 변경될 때마다 표준 라이브러리에 변경이 필요하므로 취약합니다. 또한, platform 모듈의 지원은 핵심 개발자들이 platform 모듈에서 특별한 경우를 처리하여 승인한 구현으로 제한됩니다.

sys.implementation을 사용하면 다양한 구현이 자체 sys 모듈 버전에서 값을 명시적으로 설정할 수 있습니다.

또 다른 우려는 platform 모듈이 표준 라이브러리(stdlib)의 일부라는 점인데, stdlib는 이상적으로 sys.implementation으로 옮겨질 수 있는 구현 세부 사항을 최소화해야 합니다.

sys.implementation과 platform 모듈 간의 중복은 단순히 sys.implementation으로 연기될 것입니다 (동일한 인터페이스가 platform에서 이를 래핑하는 방식으로).

Frozen Importlib의 캐시 태그 생성 (Cache Tag Generation in Frozen Importlib)

PEP 3147은 파일 이름에 모듈 캐시와 캐시 태그 사용을 정의했습니다. Python 3.3부터 Python 바이너리에 고정된 importlib 부트스트랩 코드는 가져오기(import) 프로세스 중에 캐시 태그를 사용합니다. importlib 부트스트랩 프로젝트의 일부는 더 이상 필요하지 않은 Python/import.c의 코드를 정리하는 것이었습니다.

Python/import.c에 정의된 캐시 태그는 “cpython” MAJOR MINOR로 하드코딩되었습니다. importlib의 경우, 동일한 방식으로 하드코딩하거나 platform.python_implementation()이 하는 방식과 동일하게 구현을 추측하는 옵션이 있습니다.

하드코딩된 태그가 CPython 특정 코드로 제한되는 한, 이는 용납 가능합니다. 그러나 다른 Python 구현이 importlib 코드를 사용하여 모듈 캐시와 작동하는 경우, 하드코딩된 태그는 문제가 될 것입니다.

이 경우 platform 모듈을 직접 사용하는 것은 시작부터 불가능합니다. importlib 부트스트랩에서 사용되는 모든 모듈은 내장(built-in) 또는 고정(frozen)되어야 하는데, platform 모듈은 둘 다 해당되지 않습니다. 이 시점이 sys.implementation에 대한 최근 관심을 불러일으킨 요점입니다.

사용되는 구현 이름의 결과와 관계없이, 또 다른 문제는 캐시 태그에 사용되는 버전과 관련이 있습니다. 이 버전은 언어 버전이 아닌 구현 버전일 가능성이 높습니다. 그러나 구현 버전은 표준 라이브러리 어디에서도 쉽게 식별되지 않습니다.

구현별 테스트 (Implementation-Specific Tests)

현재 Lib/test 아래의 테스트 스위트에는 여러 구현별 테스트가 있습니다. 테스트 지원 모듈(Lib/test/support.py)은 이러한 테스트를 처리하기 위한 일부 기능을 제공합니다. 그러나 platform 모듈과 마찬가지로, test.support는 sys.implementation이 불필요하게 만들 추측을 해야 합니다.

Jython의 os.name 핵 (Jython’s os.name Hack)

Jython에서는 표준 라이브러리에서 Java 환경에 대한 특별한 처리를 수용하기 위해 os.name이 'java'로 설정됩니다. 불행히도 이는 그렇지 않으면 그 자리에 올 os 이름을 가립니다. sys.implementation은 이 특별한 경우의 필요성을 없애는 데 도움이 될 것입니다. 현재 Jython은 일반적인 os.name 값으로 os._name을 설정합니다.

sys.(version|version_info|hexversion)의 문제점 (The Problem With sys.(version|version_info|hexversion))

이 PEP의 초기 버전은 sys.version_info (및 관련 속성)를 구현과 대조되는 “Python 언어의 버전”이라고 잘못 언급했습니다. 그러나 이는 사실이 아닙니다. 대신, 이는 CPython 구현의 버전입니다. 덧붙여 말하면, sys.version_info의 처음 두 구성 요소 (메이저 및 마이너)는 언어 정의의 버전도 반영합니다.

Barry Warsaw가 지적했듯이, “과거에 sys.version_info의 의미는 충분히 모호했습니다.” sys.implementation을 통해 우리는 구현 버전을 위한 명시적인 위치를 먼저 설정함으로써 이 상황을 개선할 기회를 가집니다.

이 PEP는 sys.version_info의 의미를 직접적으로 명확히 하기 위한 다른 노력을 기울이지 않습니다. 그럼에도 불구하고, 구현에 대한 명시적인 버전을 갖는 것은 언어 버전과의 구분을 명확히 하는 데 확실히 도움이 될 것입니다.

다른 Python 구현자들의 피드백 (Feedback From Other Python Implementers)

IronPython

Jeff Hardy는 피드백 요청에 응답했습니다. 그는 “승인 다음 날 바로 추가할 것”이라고 말했습니다. 그는 또한 sys.implementation의 타입과 metadata 속성(이후 PEP에서 제거됨)에 대한 유용한 피드백을 제공했습니다.

Jython

2009년에 Frank Wierzbicki는 (Jython이 필수 속성을 구현하는 것과 관련하여) 다음과 같이 말했습니다.

Jython을 대표하여 말하자면, 지금까지는 승인되면 곧바로 채택할 만한 것으로 보입니다 (저에게는 꽤 유용해 보입니다).

PyPy

일부 PyPy 개발자들은 피드백 요청에 응답했습니다. Armin Rigo는 다음과 같이 말했습니다.

저 개인적으로는 좋은 아이디어라고 생각하며, Python 3.3으로 마이그레이션할 때 기꺼이 따를 것입니다.

그는 또한 필수 목록을 작게 유지하는 것을 지지했습니다. Armin과 Laura Creighton 모두 Python 구현을 더 잘 분류하려는 노력이 환영받을 것이라고 지적했습니다. 이 PEP가 작은 시작에 불과한 그러한 노력은 별도로 고려될 것입니다.

과거의 노력 (Past Efforts)

PEP 3139

2008년의 PEP 3139는 구현별 변수와 함수를 별도의 모듈로 추출함으로써 sys 모듈을 정리할 것을 권장했습니다. PEP 421은 그 아이디어의 덜 야심 찬 버전입니다. PEP 3139는 거부되었지만, 그 목표는 훨씬 가벼운 접근 방식을 통해 PEP 421에 크게 반영되어 있습니다.

PEP 399

PEP 399는 표준 라이브러리에 대한 정책을 지시하며, 대체 구현에 더 친화적이 되도록 돕습니다. PEP 421은 동일한 정신으로 제안됩니다.

큰 그림 (The Bigger Picture)

이 PEP가 Python의 구현별 부분을 식별하고 대체 구현에 미치는 영향을 완화하기 위한 더 큰 진행 중인 노력의 작은 부분이라는 점을 다시 한번 언급할 가치가 있습니다.

sys.implementation은 구현별 데이터의 중심점이며, 언어, 표준 라이브러리 및 다양한 구현 간의 협력을 위한 연결 고리 역할을 합니다. 시간이 지남에 따라 sys.implementation이 적절한 경우 sys 및 다른 내장/표준 라이브러리 모듈의 현재 속성을 가정하는 것이 가능해집니다. 이러한 방식으로, 이는 PEP 3137의 경량 버전이지만, 가능한 한 작게 시작됩니다.

그러나 이미 언급했듯이, 다른 많은 노력들이 sys.implementation보다 선행됩니다. 또한, 이것이 반드시 노력의 주요 부분인 것도 아닙니다. 오히려, Python을 대체 구현에 더 친화적으로 만들기 위한 노력의 인프라의 일부로 간주하십시오.

대안 (Alternatives)

sys 아래의 단일 네임스페이스 접근 방식은 비교적 간단하므로, 이 PEP에 대한 다른 대안은 고려되지 않았습니다.

기타 속성 예시 (Examples of Other Attributes)

다음은 예시일 뿐이며 제안의 일부가 아닙니다. 대부분은 이전 논의 중에 제안되었지만, 이 PEP의 목표에 맞지 않았습니다. (만약 이들이 흥미를 유발한다면 “새로운 필수 속성 추가 (Adding New Required Attributes)”를 참조하십시오.)

  • common_name: 구현이 알려진 대소문자 구분 이름.
  • vcs_url: 구현 프로젝트의 주요 VCS (버전 관리 시스템) 저장소 URL.
  • vcs_revision_id: 구현의 VCS 리비전을 식별하는 값.
  • build_toolchain: 인터프리터를 빌드하는 데 사용된 도구.
  • build_date: 인터프리터가 빌드된 타임스탬프.
  • homepage: 구현 웹사이트의 URL.
  • site_prefix: 구현에 선호되는 사이트 접두사.
  • runtime: 인터프리터가 실행되는 런타임 환경 (예: “.NET CLR” 또는 “Java Runtime Executable”과 같은 “Common Language Runtime”).
  • gc_type: 사용되는 가비지 컬렉션 유형 (예: “참조 카운팅” 또는 “마크 앤 스윕”).

해결되지 않은 문제 (Open Issues)

현재 없음.

구현 (Implementation)

이 PEP의 구현은 이슈 #14673에서 다루어집니다.

참조 (References)

문서 원문에 포함된 참조 목록을 확인해주세요.

이 문서는 퍼블릭 도메인에 공개되었습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments