PEP 729 – 타입 관리 프로세스

Author:: Jelle Zijlstra <jelle.zijlstra at gmail.com>, Shantanu Jain <hauntsaninja at gmail.com>
Discussions-To:: Discourse thread
Status:: Active
Type:: Process
Topic:: Governance, Typing
Created:: 19-Sep-2023
Post-History:: 04-Oct-2023, 20-Sep-2023
Resolution:: 20-Nov-2023

Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 파이썬 타입 시스템을 관리하는 새로운 방식을 제안합니다. 즉, 파이썬 타입 시스템의 유지 관리와 개발을 담당하는 협의회를 구성합니다. 협의회는 사양과 적합성 테스트 모음을 유지 관리하며, 처음에는 파이썬 운영위원회가 임명합니다.

파이썬 타입 시스템은 거의 10년 전 PEP 484에 의해 만들어졌습니다. 현재 타입 시스템은 널리 사용되고 있으며, 타이핑은 훌륭하고 유지 관리 가능한 파이썬 코드를 작성하는 데 중요한 도구가 되었습니다. 더 많은 사용 사례를 포괄하고 사용 편의성을 개선하기 위해 타입 시스템에 많은 변화가 이루어졌습니다. 여러 타입 검사기가 만들어졌으며, 각각 고유한 강점을 지니고 있습니다. 타입 어노테이션 구문은 인기 있는 dataclasses 모듈, Pydantic와 같은 패키지를 통한 런타임 타입 검사 및 검증, mypyc와 같은 도구를 통한 정적 컴파일 등 파이썬 생태계의 여러 주요 혁신을 이끌었습니다.

그러나 타입 시스템이 성장하면서 현재 타입 시스템을 관리하는 방식과 관련된 여러 문제가 드러났습니다.

PEP가 유일한 사양입니다

파이썬 타입 시스템은 처음에 PEP(PEP 484)에 의해 만들어졌으며, 타입 시스템에 대한 변경은 여전히 PEP를 통해 이루어집니다. 파이썬 타입 시스템에 사양이라는 것이 존재하는 범위에서, 그 사양은 이 PEP 시리즈로 구성됩니다. 그러나 표준 트랙 PEP는 지속적으로 갱신되는 문서나 사양을 목적으로 하지 않으며, 변경 제안입니다.

한 가지 예를 통해 이 문제를 설명할 수 있습니다. 이와 같은 시기에 PEP 484에 의해 typing모듈이 도입되었으며, PEP 3156은 Python 3의 성공에 크게 기여한 또 하나의 주요 신기능인 asyncio모듈을 도입했습니다. 두 모듈은 처음 만들어진 이후 크게 발전했으며 핵심 언어의 변화를 이끌었습니다.

그러나 asyncio와 typing은 본질적으로 중요한 측면에서 다릅니다. asyncio를 사용하는 사용자는 표준 라이브러리 자체와만 상호 작용하는 반면, typing 사용자는 외부 도구인 타입 검사기도 고려해야 합니다. 파이썬 언어 레퍼런스는 typing 모듈의 기호를 다루지만, 전체 타입 시스템을 타입 검사기가 어떻게 해석해야 하는지는 자세히 다루지 않습니다(또한 다루어서도 안 됩니다). 현재 그러한 내용은 PEP에만 존재합니다.

이 문제는 PyPA specifications을 별도로 유지하여 해결하려는 패키징 생태계에도 해당합니다.

사양을 발전시키기 어렵습니다

PEP가 우리가 가진 유일한 사양이므로, 사양의 변경으로 간주될 수 있는 모든 사항에는 이론적으로 새 PEP가 필요합니다. 그러나 작은 변경에 이 과정은 너무 부담스러운 경우가 많습니다. 때로는 기존 PEP를 직접 변경하기도 하지만, 이는 승인되고 구현된 PEP가 더 이상 변경해서는 안 되는 역사적 문서가 된다는 생각에 어긋납니다.

몇 가지 구체적인 예는 다음과 같습니다.

PEP 484는 typing.NoReturn을 인자 어노테이션에 사용할 수 없다고 명시적으로 말합니다. 그럼에도 타입 검사기는 오랫동안 이러한 사용을 허용해 왔습니다.
2023 discussion에서는 PEP 561의 부분 스텁 설명이 불명확하며 주요 타입 검사기가 명시된 대로 정확히 구현하지 않았다는 점을 지적했습니다.
널리 사용되는 서드파티 typing_extensions 패키지는 새로운 타입 시스템 기능의 백포트를 제공합니다. 타입 검사기는 이 모듈의 기호를 typing의 기호와 동일하게 취급해야 하지만, 이는 어떤 PEP에도 명시적으로 규정되어 있지 않습니다.

타입 시스템의 명세가 불충분합니다.

PEP는 명세를 제공하지만, 흔히 충분히 정확하지 않습니다(때로는 의도적으로 그렇습니다). 이는 타입 시스템의 조합적 복잡성이 증가함에 따라 특히 그러합니다.

결국 명세가 불충분한 영역을 어떻게 다룰지는 개별 타입 검사기가 결정하게 됩니다. 타입 검사기들이 비공식적으로 조율하는 경우, 이는 어디에도 명확히 기록되지 않은 사실상의 표준으로 이어져 타입 시스템을 처음 접하는 사람들이 접근하기 어렵게 만듭니다. 예를 들면 다음과 같습니다:

@overload 매칭이 작동하는 방식입니다.
ParamSpec이 어떻게 작동해야 하는지 메서드에서 결정하는 방식입니다.
재귀적 별칭이라는 개념입니다.
변수 초기화의 의미론입니다.
__exit__의 어노테이션에 대한 도달 가능성 의미론입니다.
기호 가시성입니다.
완전성 검사를 위한 NoReturn 사용입니다.

Steering Council은 위 문제를 해결하기에 적합하지 않습니다.

SC는 전체 언어를 관할 범위로 삼고 있으며, 순전히 타입 시스템에 관한 결정을 내리기에 적합하지 않습니다 – 다른 책임과 함께 타입 시스템의 난해한 세부 사항까지 다룰 시간이 없기 때문입니다. 이는 Steering Council이 때때로 PEP 위임을 사용하는 이유와 취지가 비슷합니다.

지지입니다.

이 PEP는 Rebecca Chen (pytype), Eric Traut (Pyright), 그리고 mypy 및 Pyre 유지 관리자들의 비공개 지지를 포함하여, 모든 주요 타입 검사기의 유지 관리자들로부터 지지를 받았습니다.

명세입니다.

Typing Council이라는 새로운 그룹을 설립할 것을 제안합니다. 이 그룹은 Python 타입 시스템을 개발하고 유지 관리하며, 위 문제를 해결할 책임을 집니다.

“operations and process” 섹션에서는 이 그룹이 어떻게 운영되고 관리될지를 설명합니다.

더 흥미로운 “projects” 섹션에서는 Typing Council이 이끌어 나갈 수 있는 위 문제에 대한 해결책을 설명합니다.

권한입니다.

Typing Council의 권한은 Python 타입 시스템이 다음을 보장하도록 하는 것입니다:

유용함: 타입 시스템은 일반적인 사용 사례를 지원해야 합니다. 주요 사용 사례는 정적 분석이며, PEP 484에서 확인했듯이 런타임 타입 검사, 정적 컴파일, IDE 지원, 문서화와 같은 다른 사용 사례도 있습니다. Typing Council은 결정을 내릴 때 이러한 모든 사용 사례를 고려해야 하며, 추가 사용 사례가 등장하면 이를 지원하는 데에도 열려 있어야 합니다.
사용 가능함: 타입 시스템은 Python 개발자가 쉽게 사용할 수 있어야 합니다. 타입 검사기가 허용하는 올바르게 타입이 지정된 Python 코드를 편리하게 작성할 수 있어야 합니다. 타입 시스템에 대한 양질의 문서가 있어야 합니다.
안정적: 타입 시스템이 성숙함에 따라 사용자는 타입이 지정된 코드가 계속 작동할 것이라고 믿고, 타입 시스템에 대한 자신의 멘탈 모델을 신뢰할 수 있어야 합니다. 변경은 신중하게, 그리고 혼란을 최소화하는 방식으로 이루어져야 합니다. 그럼에도 타입 시스템은 발전할 수 있어야 하며, 타입 검사기 동작에 Python 자체와 동일한 호환성 지침을 적용하는 것은 타당하지 않습니다. 물론 typing 모듈에 있는 객체의 존재와 런타임 동작은 Python의 PEP 387 표준 호환성 정책을 따릅니다.

운영 및 절차

위원회는 Python 핵심 개발자와 주요 타입 검사기의 유지 관리자 같은 저명한 커뮤니티 구성원 3~5명으로 구성됩니다. 구성원에는 타입 검사기, CPython, typeshed 또는 기타 프로젝트를 포함할 수 있는 다양한 타입 검사 관련 프로젝트에 소속된 사람들이 포함되어야 합니다.

위원회의 초기 구성원은 다음과 같습니다:

Eric Traut (Pyright; PEP 647, PEP 681, PEP 695 작성자)
Guido van Rossum (핵심 개발자; PEP 484 및 PEP 526 작성자)
Jelle Zijlstra (핵심 개발자; typeshed; pyanalyze; PEP 688 및 PEP 702 작성자)
Rebecca Chen (pytype)
Shantanu Jain (핵심 개발자; typeshed; mypy)

현재 위원회 구성원은 python/typing-council 저장소에 기록되어 있습니다.

위원회 구성원에게는 임기 제한이 없습니다. 위원회 구성원은 언제든지 직위를 사임할 수 있습니다. 각 구성원은 사임하기 전에 연속해서 최대 5년 동안 재임할 것으로 예상합니다.

공석이 발생하고 남은 구성원이 3명 이상인 경우, 새 구성원을 임명할지는 위원회가 결정합니다. 후임자를 결정하기 위해 타이핑 커뮤니티에서 후보 추천을 받습니다. 자기 추천도 허용됩니다. 그런 다음 현 타이핑 위원회가 후보자 중에서 후임 구성원을 결정합니다. 이는 전적으로 재량에 따라 이루어질 것으로 예상되지만, 타이핑 위원회는 투표를 포함하여 적절하다고 판단하는 어떤 방법으로든 후임자를 선택할 수 있습니다.

타이핑 위원회는 운영 위원회에 계속해서 책임을 집니다. 운영 위원회는 언제든 어떤 이유로든 타이핑 위원회의 구성에 대해 구체적인 변경을 직접 제시하거나, 특정되지 않은 변경을 요청할 수 있습니다.

이것이 그다지 민주적이지 않은 구조이며 타이핑 위원회를 크게 신뢰해야 하는 구조임을 인정합니다. 그러나 Python 커뮤니티는 그다지 민주적이지 않은 구조로도 오랫동안 성공해 온 역사를 가지고 있습니다! 우리는 자치, 구성원의 순환, 그리고 운영 위원회에 대한 책무성이 타이핑 위원회가 커뮤니티의 요구를 충족하고 있음을 보장하기에 충분하다고 믿습니다.

위원회는 주로 GitHub PR 검토를 통해 운영됩니다. 정기 회의는 필요하지 않을 가능성이 높지만, 위원회는 화상 통화, 비공개 채팅 또는 내부적으로 결정하는 그 밖의 수단을 마련할 수 있습니다.

위원회는 투명성을 지향하여 가능한 경우 근거와 함께 discuss.python.org에 모든 결정을 공개적으로 게시해야 합니다. 결정을 내리기 전에 위원회는 관심 있는 모든 커뮤니티 구성원에게 의견을 제시할 기회를 제공해야 합니다. 토론 시작과 위원회의 결정 사이에는 최소 일주일의 기간이 있어야 합니다.

위원회 구성원은 PEP를 후원할 자격을 갖습니다. 이 PEP가 수락되면, 이 사실을 명시하도록 PEP 1을 수정해야 합니다.

운영 위원회와의 관계

현재와 마찬가지로 Python 운영 위원회는 Python 언어의 전반적인 방향을 책임지고, 타이핑 관련 PEP에 대한 결정을 계속 내립니다. 타이핑 위원회는 타이핑 관련 PEP에 관해 운영 위원회에 서면 의견과 권고를 제공합니다.

그러나 타입 시스템에 대한 소규모 변경은 타이핑 위원회가 직접 수행할 수 있습니다. 운영 위원회는 일부 PEP에 대한 결정을 타이핑 위원회에 위임할 수도 있습니다(다른 PEP 위임과 정확히 같은 방식입니다).

이 모델에서 과거 및 최근의 사안이 처리될 수 있었던 방식의 몇 가지 예는 다음과 같습니다.

언어 구문을 변경하는 PEP 695(타입 매개변수 구문)와 같은 PEP는 운영 위원회가 결정해야 하며, 타이핑 위원회는 의견이나 지지만 제시합니다. 마찬가지로 PEP 702(사용 중단)와 같은 PEP는 순수한 타이핑을 넘어서는 런타임 동작과 관련되므로 운영 위원회가 결정합니다. 운영 위원회가 결정해야 하는 다른 예로는 PEP 718(첨자화 가능한 함수)과 PEP 727(문서 메타데이터)이 있습니다.
타입 검사기 사용자에게만 영향을 미치고 전체 언어를 변경하지 않는 PEP 698(@override)과 같은 PEP도 기본적으로 운영 위원회가 결정합니다. 그러나 이러한 PEP는 결정을 위해 타이핑 위원회에 위임할 수 있습니다(다른 PEP 위임과 마찬가지입니다). 잠재적으로 위임할 수 있는 PEP의 다른 예로는 PEP 647(타입 가드), PEP 655(개별 필수 TypedDict 항목), PEP 673(Self), PEP 675(Literal)이 있습니다.
예를 들어 typing.Never를 typing.NoReturn의 별칭으로 추가하는 것과 같은 소규모 기능의 추가는 사양 및 적합성 테스트 모음에 대한 PR을 통해 이루어집니다. 그러면 타이핑 위원회가 해당 PR을 병합할지 결정합니다. 타이핑 위원회가 필요하다고 판단하면 해당 기능을 PEP로 명세화하고 논의하도록 요청할 수 있습니다.
partial stubs in PEP 561에서 최근 발생한 것처럼 사양의 일부 해석에 혼란이 있는 경우, 누군가 타이핑 사양을 명확히 하기 위한 PR을 작성하고 타이핑 위원회가 사양 변경을 결정합니다.

런타임 typing 모듈은 계속해서 CPython 핵심 개발자 팀이 유지 관리합니다. 그러나 타입 검사기 동작에 영향을 미치는 런타임 모듈의 모든 변경은 사양 변경(아래 참조)과 함께 이루어져야 하며 타이핑 위원회의 승인을 받아야 합니다. 예를 들어 Python 3.11에서 핵심 개발자들은 새 함수 typing.assert_type()를 추가했습니다. 타이핑 위원회가 존재했다면 이 변경에는 이에 상응하는 사양 변경과 타이핑 위원회의 승인이 필요했을 것입니다. 한편 Python 3.11에는 검사 기능 도우미인 typing.get_overloads()도 추가되었습니다. 이 함수는 타입 검사기 동작에 영향을 미치지 않으므로 타이핑 위원회의 승인이 필요하지 않습니다. 그러나 런타임 타입 검사기에 대한 지원은 위원회의 소관에 포함되므로, 위원회는 이러한 변경을 모니터링하고 적절한 경우 피드백을 제공해야 합니다.

타입 검사기와의 관계

타이핑 위원회는 타입 검사기에 대한 직접적인 권한이 없으며, 특정 기능을 구현하거나 동작을 변경하도록 강제할 수 없습니다. 타입 검사기는 위원회가 정한 사양을 따를 동기를 갖습니다. 이를 통해 사양에 따른 타이핑 정보를 제공하는 라이브러리, typeshed의 스텁 파일, typing 표준 라이브러리 모듈, 표준 타입 시스템을 다루는 사용자 문서와 같은 공유 리소스를 활용할 수 있기 때문입니다. 타입 검사기는 타입 시스템을 자유롭게 확장하거나 사양에서 벗어날 수 있지만, 그러한 차이점을 명확히 문서화해야 합니다.

타입 검사기가 타이핑 위원회의 모든 결정을 구현해야 한다는 사실은 위원회에 유용한 제동 장치로 작용하여, 위원회의 결정이 보수적이고 충분히 검토되도록 합니다. 개별 타입 검사기는 적절하다고 판단하는 방식으로 자유롭게 혁신할 수 있으며, 성공적인 혁신은 표준 타입 시스템에 통합될 수 있습니다.

프로젝트

다음은 타이핑 위원회가 담당할 몇 가지 노력입니다.

적합성 테스트 모음

적합성 테스트 모음은 타입 검사기가 Python 코드를 어떻게 검사해야 하는지에 대한 기계 검사 가능한 문서를 제공하며, 주요 타입 검사기 구현의 테스트 모음 실행 결과도 함께 제공합니다. 이것이 어떤 모습일 수 있는지에 대한 대략적인 초안은 created by Shantanu입니다.

여기에는 이전 PEP에서 규정한 동작에 대한 규범적 테스트와, 어떤 표준에서도 규정하지 않은 영역에서 기존 구현의 동작을 문서화할 수 있도록 하는 서술적 테스트가 포함됩니다. 이러한 설명은 아래의 작업 방향을 정하고 표준화의 중점 영역을 식별하는 데 유용합니다.

타입 시스템 사양

사양은 처음에는 기존 PEP의 사양 섹션을 이어 붙여 작성하고, 이후 혼동되는 부분을 명확히 하며 더 많은 영역을 다루도록 점진적으로 개선합니다. 이렇게 이어 붙인 사양의 초안은 created by Jelle입니다.

이 사양에는 몇 가지 대상 독자가 있습니다.

타입 검사기에는 이상화된 타입 검사기가 어떻게 동작해야 하는지에 대한 설명을 제공합니다. 개별 타입 검사기는 서로 다른 목표와 기술적 제약을 가지고 있으므로, 이를 완전히 구현할 자원이 없거나 다른 동작이 사용자에게 더 나은 서비스를 제공한다고 판단하는 경우 사양에서 벗어날 수 있습니다. 그러나 그러한 사양과의 차이는 문서화해야 합니다.
typeshed와 같은 프로젝트나 여러 타입 검사기와 호환되기를 원하는 라이브러리에는 타입 검사기가 코드를 이해할 수 있도록 따를 수 있는 규칙 집합을 제공합니다.
타입 시스템의 변경을 제안하려는 사람들에게는 새로운 제안을 위한 기반을 제공합니다.

특히 이 사양은 typing을 사용하는 애플리케이션 개발자를 대상으로 하지 않습니다. 이러한 사용자는 일반적으로 타입 검사기 간의 호환성에 대해 걱정할 필요가 없습니다. 이들에게는 다음 절에서 설명하는 보다 비공식적인 사용자 대상 참조 문서가 더 적합합니다.

커뮤니티 내에는 이러한 사양이 얼마나 형식적이어야 하는지에 대해 서로 다른 의견이 있습니다. 이 문서는 기존 사양을 기반으로 하는 점진적 접근 방식을 권장하지만, 최종 상태를 규정하는 것을 목표로 하지는 않습니다. 타이핑 위원회는 커뮤니티가 원하는 형식화 수준에 맞춰 사양이 발전할 수 있도록 하는 메커니즘을 제공하며, 예를 들어 사양을 더 잘 형식화하기 위한 수단으로 Kevin Millikin의 document on “Python Static Types”의 일부를 통합할 수 있습니다.

PEP를 포함한 사양에 대한 제안된 변경 사항에는 일반적으로 다음이 함께 수반되어야 합니다.

변경 사항이 각자의 타입 검사기에서 구현되고 유지 관리될 수 있음을 확인하는 타입 검사기 유지 관리자들의 동의가 필요합니다.
기존 기능을 변경하는 경우에는 기존 타입 검사기의 동작에 대한 조사가 필요합니다. 기존 타입 검사기들이 대략 비슷하게 동작한다면, 이들이 공유하는 동작을 사양의 일부로 만들어야 한다는 증거가 됩니다.
지정된 동작을 입증하는 적합성 테스트 모음의 변경 사항이 필요합니다.

타입 시스템의 사용자 대상 참조 문서

문서는 Python 타입 시스템의 성공에 중요하므로, 타이핑 위원회는 타입 시스템에 대한 양질의 문서가 마련되도록 해야 합니다.

앞서 언급했듯이 PEP는 명확히 설명하기 어려운 여러 대상 독자를 겨냥한 특정 시점의 변경 제안입니다. 따라서 PEP는 사용자 문서로 적합하지 않습니다. 이전 절에서 논의한 사양은 살아 있는 문서가 되겠지만, 일반적인 사용법을 위한 문서로 활용하기에는 지나치게 기술적일 가능성이 높습니다.

따라서 타입 시스템을 위한 별도의 사용자 대상 참조 문서가 유용합니다. 이러한 노력은 typing.python.org의 문서를 확장하고 개별 타입 검사기의 문서 섹션과 CPython 문서의 자료를 재사용할 수 있습니다.

개정 사항

이 PEP는 Typing Council의 헌장 역할을 합니다. 운영 변경은 새 PEP를 통해서나 이 PEP를 변경하여 이루어질 수 있습니다. 어느 경우든 해당 변경은 커뮤니티에서 논의한 후 Steering Council이 결정합니다.

거부된 아이디어

처음부터 사양 작성하기

이 PEP는 기존 PEP에서 시작하여 필요에 따라 사양을 명확히 하고 개선함으로써 타이핑 사양을 작성할 것을 제안합니다. 일부 커뮤니티 구성원은 전체 타입 시스템을 다루는 새롭고 더 형식적인 사양을 작성하며 처음부터 시작하는 것을 선호합니다. 이는 사양을 위한 더 탄탄한 기반을 제공할 수 있습니다.

그러나 이는 훨씬 더 큰 작업이 될 것입니다. Kevin Millikin이 진행 중인 기존 형식화 노력은 좋은 출발점이지만, 지금까지는 PEP 484의 일부만 다룹니다. PEP 484 이후에야 typing.Protocol, typing.Literal, typing.TypedDict와 같은 주요 타입 시스템 기능이 도입되었다는 점을 고려하면, 타입 시스템의 나머지 부분을 다루려면 아마도 몇 배 더 많은 노력이 필요할 것입니다. 커뮤니티에 이러한 거대한 작업을 수행할 의욕이 있기나 한지는 분명하지 않습니다. 누군가 사양을 작성하는 모든 작업에 나선다고 하더라도, 커뮤니티 구성원과 타입 검사기 유지 관리자는 사양이 현재 동작을 정확히 반영하는지, 그렇지 않다면 사양과 타입 검사기 중 무엇을 변경해야 하는지를 검토하는 데 많은 노력을 들여야 합니다.

기존 PEP에서 시작하면 품질이 더 낮은 사양이 만들어지지만, Typing Council은 사양을 개선하고 명확히 함으로써 타입 시스템의 어느 부분에서든 즉시 변화를 만들어 낼 수 있습니다. 형식화 노력은 사양의 각 부분을 점진적으로 교체하는 방식으로도 계속 진행할 수 있습니다.

대안적 거버넌스 메커니즘

이 PEP의 이전 초안에서는 Steering Council이 매년 Typing Council의 구성원을 임명할 것을 제안했습니다. 현 Steering Council은 Typing Council이 자체적으로 조직되도록 하고 Steering Council이 Typing Council을 지속적으로 감독해야 할 필요를 피하는 편이 더 낫다고 제안했습니다.

더 민주적인 방식을 포함하여 대안적 거버넌스 메커니즘도 가능하지만, 이러한 방식은 일반적으로 여러 까다로운 문제를 제기하고 훨씬 더 많은 절차를 요구하며 잠재적으로 더 분열을 초래합니다. 예를 들어 PEP 8000 시리즈나 다른 Python 하위 커뮤니티의 대안적 거버넌스에 관한 최근 논의를 참조하십시오. 궁극적으로 Typing Council은 Steering Council의 권한 아래 존재하므로, 거버넌스를 출범시키고 책무성 메커니즘으로 기능하는 데 Steering Council에 의존할 수 있습니다.

Python 개선 제안 한국어 번역