PEP 731 – C API 작업 그룹 헌장
- Author:
- Guido van Rossum <guido at python.org>, Petr Viktorin <encukou at gmail.com>, Victor Stinner <vstinner at python.org>, Steve Dower <steve.dower at python.org>, Irit Katriel <irit at python.org>
- Discussions-To:
- Discourse thread
- Status:
- Active
- Type:
- Process
- Topic:
- Governance
- Created:
- 11-Oct-2023
- Post-History:
- 13-Oct-2023, 23-May-2024, 19-Jun-2024
- Resolution:
- Discourse message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 Python C API의 개발과 유지 관리를 감독하고 조정하는 책임을 맡은 소규모 Python 핵심 개발자 위원회인 C API 작업 그룹을 설립할 것을 제안합니다.
작업 그룹은 Python의 C API와 관련된 문서, 테스트 모음 및 도구를 유지 관리합니다. Steering Council이 위임한 바에 따라, 이 그룹은 개별 API 함수나 타입 등의 추가 또는 제거부터 다소 급진적인 성격의 새로운 설계 수용에 이르기까지 C API의 변경 사항을 결정하는 기관입니다.
작업 그룹의 임무는 모든 Python 사용자의 이익을 대변하는 것이지만, 특히 CPython 환경에서 Python의 C API를 사용하는 코드, 대체 Python 구현을 사용하는 코드 또는 다른 프로그래밍 언어(C++ 및 Rust 등)를 위한 바인딩 프레임워크를 사용하는 코드의 모든 유지 관리자 이익을 대변하는 것입니다.
작업 그룹은 Python Steering Council의 뜻에 따라 활동합니다. 이 문서는 작업 그룹의 헌장입니다.
서문
- Python은 무엇에서 이름을 따왔습니까?
- Python 2의 EOL은 언제였습니까?
- CPython C API를 발전시키는 최적의 전략은 무엇입니까?
동기
핵심 개발자 스프린트와 Language Summit에서 많은 논의와 대면 회의가 있었고 C API의 문제와 이해관계자를 철저히 조사했음에도 불구하고, 다음을 포함하되 이에 국한되지 않는 많은 논쟁적인 사안에 대해 합의에 도달하지 못했습니다.
- 새로운 API 함수를 설계하기 위한 규칙
- 호환성 처리 방법
- 오류를 처리하는 최선의 전략
- Stable ABI와 Limited API의 미래
- 핸들 기반 API 규칙으로 전환할지 여부(및 그 방법)
소규모의 신뢰할 수 있는 결정권자 그룹 없이는 진전을 이루기 어려울 만큼 이해관계자, 제안, 요구 사항, 제약 조건 및 규칙이 너무 많다는 것이 전반적인 의견입니다.
2023년 솔트레이크시티 Language Summit에서 문제 목록 작성을 시작하기로 결정했습니다. 2023년 브르노 핵심 개발자 스프린트에서 이 작업은 거의 완료되었으며, 논의 후 다음 단계는 우리가 영원히 진전을 이루지 못하는 일이 없도록 작업 그룹을 설립하는 것이라는 결론에 이르렀습니다.
Steering Council은 입장을 밝혔으며 정식 설립을 염두에 두고 그러한 작업 그룹에 C API에 관한 결정을 위임하고자 합니다.
사양
새로운 그룹인 C API 작업 그룹을 만들 것을 제안합니다. 이 그룹은 Python C API의 개발과 유지 관리를 감독하고 조정하는 책임을 맡습니다. 이를 위해 작업의 기반이 되는 원칙을 수립하고 핵심 개발자가 참고할 수 있는 지침을 발표합니다.
아래의 “운영 및 절차” 절에서는 작업 그룹의 운영 방식과 관리 방식을 설명합니다.
구성원
작업 그룹의 구성원은 다음과 같습니다.
- Erlend Aasland
- Petr Viktorin
- Serhiy Storchaka
- Steve Dower
- Victor Stinner
권한
작업 그룹의 권한은 Python C API를 사용하는 모든 사용자와 API에 기여하는 모든 사람에게 해당 API가 적합하도록 보장하는 것이며, 어느 한 그룹을 다른 그룹보다 부당하게 우선시하지 않는 것입니다. 작업 그룹은 대표적인 이해관계자와 그들의 필요 및 선호를 파악하고, 이러한 필요를 공평하고 지속 가능한 방식으로 충족하기 위한 계획을 결정합니다. 작업 그룹은 해당 계획의 실행을 감독합니다.
운영 및 절차
작업 그룹은 저명한 Python 핵심 개발자로 구성된 최소 세 명의 구성원으로 이루어집니다. 구성원은 다양한 이해관계자의 필요를 신중하게 고려해야 합니다.
Steering Council이 최초의 작업 그룹을 임명합니다. 작업 그룹 구성원에게는 임기 제한이 없습니다. 작업 그룹 구성원은 언제든지 어떤 이유로든 직위를 사임할 수 있습니다. 시간이 지남에 따라 구성원이 변경될 것으로 예상합니다.
교체 구성원을 결정하기 위해 핵심 개발자 커뮤니티에서 추천을 받습니다. 자기 추천도 허용됩니다. 기존 작업 그룹은 추천된 사람들 가운데서 교체 구성원을 결정합니다. 이 과정은 일방적으로 진행될 것으로 예상하지만, 작업 그룹은 투표를 포함하여 적절하다고 판단하는 어떤 방법으로든 교체 구성원을 선택할 수 있습니다.
작업 그룹은 Steering Council에 계속해서 책임을 집니다. Steering Council은 언제든지 어떤 이유로든 작업 그룹의 구성에 대해 특정 변경을 공개적으로 또는 비공개로 시행하거나, 구체적으로 명시하지 않은 변경을 요청할 수 있습니다.
이것이 특별히 민주적인 구조가 아니며 작업 그룹을 상당히 신뢰해야 하는 구조임을 인정합니다. 그러나 Python 커뮤니티는 완전히 민주적이지 않은 구조로도 성공해 온 오랜 역사가 있습니다! 우리는 자기 통치, 구성원의 순환적 교체, 그리고 Steering Council에 대한 책임이 C API 작업 그룹이 커뮤니티의 필요를 충족하도록 보장하기에 충분하다고 믿습니다.
작업 그룹은 주로 GitHub 이슈와 PR을 검토하는 방식으로 운영될 수 있습니다. 정기 회의는 아마 필요하지 않겠지만, 작업 그룹은 화상 통화, 비공개 채팅 또는 내부적으로 결정한 그 밖의 어떤 메커니즘이든 설정할 수 있습니다.
작업 그룹은 투명성을 목표로 삼고, 가능한 경우 근거를 함께 제시하여 모든 결정을 discuss.python.org에 공개적으로 게시해야 합니다. 결정을 내리기 전에 작업 그룹은 관심 있는 모든 커뮤니티 구성원에게 (서로 다른 이해관계자 범주의 예로서) 의견을 제시할 기회를 제공해야 합니다. 토론이 시작된 시점과 작업 그룹의 결정 사이에는 최소 일주일의 기간이 있어야 합니다.
Steering Council과의 관계
오늘날과 마찬가지로 Python Steering Council은 Python C API의 전반적인 방향에 대한 책임을 계속 지며, 표준 PEP 검토 절차(커뮤니티 토론 등)를 사용하여 C API와 관련된 PEP에 대한 결정을 계속 내립니다. C API 작업 그룹은 C API와 관련된 PEP에 대해 서면 의견과 권고를 Steering Council에 제공합니다.
그러나 작업 그룹은 더 작은 C API 변경 사항을 직접 적용할 수 있습니다. Steering Council은 일부 PEP에 대한 결정을 작업 그룹에 위임할 수도 있습니다(다른 PEP 위임과 정확히 동일한 방식입니다).
개정
이 PEP는 작업 그룹의 헌장 역할을 합니다. 작업 그룹의 운영 변경은 새 PEP를 통해서나 이 PEP를 변경하는 방식을 통해서나 수행할 수 있습니다. 어느 경우든 커뮤니티에서 논의한 후 Steering Council이 변경 사항을 결정합니다.
연락처
C API 작업 그룹에 결정을 요청하려면 커뮤니티 구성원은 capi-workgroup/decisions 저장소에 이슈를 열 수 있습니다.
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.