PEP 11 – CPython 플랫폼 지원
- Author:
- Martin von Löwis <martin at v.loewis.de>, Brett Cannon <brett at python.org>
- Status:
- Active
- Type:
- Process
- Created:
- 07-Jul-2002
- Post-History:
- 18-Aug-2007, 14-May-2014, 20-Feb-2015, 10-Mar-2022, 21-Nov-2025
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 운영체제(플랫폼)가 CPython에서 지원되게 되는 과정, 현재 지원되는 플랫폼이 무엇인지, 그리고 과거의 지원 내역을 문서화합니다.
근거
시간이 흐르면서 CPython 소스 코드에는 다양한 플랫폼별 코드 조각들이 쌓여왔으며, 이들은 한때 특정 플랫폼에서 CPython을 사용하기 위해 필요하다고 여겨졌던 것들입니다. 이 플랫폼에 접근할 수 없으면, 이 코드가 여전히 필요한지 판단할 수 없습니다. 그 결과, 이 코드는 CPython이 발전하는 과정에서 깨질 수도 있고, 플랫폼 역시 함께 발전함에 따라 불필요해질 수도 있습니다.
이러한 조각들이 계속 늘어나도록 방치하면 유지보수 불가능이라는 위험이 발생합니다: 수많은 플랫폼에 대한 전문가 없이는, CPython 소스 코드에 대한 특정 변경이 지원되는 모든 플랫폼에서 동작할지 판단할 수 없습니다. 이 위험을 줄이기 위해, 이 PEP는 어떤 플랫폼이 CPython 코어 팀에 의해 지원되는 것으로 간주되기 위해 필요한 사항을 명시하며, 사용자가 거의 없거나 전혀 없는 플랫폼에 대한 코드를 제거하는 절차 또한 제공합니다.
반면, 메인 저장소에 이러한 조각들을 허용하는 것은 협업을 촉진할 수 있고, 코드베이스에서 이식성이 낮은 부분을 식별하는 데 도움이 될 수 있으며, “새로운” 플랫폼에 대한 지원을 부트스트랩하는 데 필요합니다. 이 PEP는 어떤 플랫폼이 “지원되지 않음”이라는 것이 무엇을 의미하는지, 그리고 코어 팀이 그러한 플랫폼에 대한 코드를 어떻게 다루는지를 명시합니다.
이 PEP는 또한 CPython 개발 팀이 직접 지원하는 플랫폼을 명시적으로 나열합니다.
지원 등급
플랫폼 지원은 등급으로 나뉩니다. 각 등급에는 서로 다른 요구 사항이 따르며, 이는 지원에 대해 서로 다른 약속으로 이어집니다.
어느 티어로 승격되려면 운영 위원회의 지원이 필요하며, 이는 팀의 합의에 의해 주도될 것으로 예상됩니다. 더 낮은 티어로의 강등은 릴리스 관리자 또는 운영 위원회의 판단에 따라 특정 플랫폼이 현재 티어의 요구 사항을 장기간 충족하지 못할 때 발생합니다. 새 기능 릴리스의 b1 시점까지 어떤 티어의 요구 사항도 충족하지 못하는 플랫폼에 대해서는, 해당 플랫폼에 대한 지원이 곧 제거될 예정임을 커뮤니티에 경고하는 공지가 이루어집니다(예: b1 공지문에서). 첫 번째 릴리스 후보 시점까지 최소 하나의 티어에 부합하도록 조정되지 않은 플랫폼은 이 PEP에서 지원되지 않는 것으로 명시됩니다.
티어 1
- STATUS
- CI 실패는 릴리스를 막습니다.
main브랜치를 손상시키는 변경 사항은 병합이 허용되지 않으며, 손상이 발생하면 즉시 수정하거나 되돌려야 합니다.- 모든 코어 개발자는
main, 그리고 이에 따라 이 플랫폼들이 정상적으로 동작하도록 유지할 책임이 있습니다. - 이 플랫폼들에서의 실패는 릴리스를 막습니다.
| 대상 트리플 | 참고 사항 |
|---|---|
| aarch64-apple-darwin | clang |
| aarch64-unknown-linux-gnu | glibc, gcc |
| i686-pc-windows-msvc | |
| x86_64-pc-windows-msvc | |
| x86_64-unknown-linux-gnu | glibc, gcc |
Tier 2
- STATUS
- 신뢰할 수 있는 빌드봇이 있어야 합니다.
- 최소 두 명의 코어 개발자가 해당 플랫폼을 지원하기로 등록되어 있어야 합니다.
- 이 플랫폼들 중 어느 것이든 깨뜨리는 변경 사항은 24시간 이내에 수정되거나 되돌려져야 합니다.
- 이 플랫폼들에서의 실패는 릴리스를 막습니다.
| 대상 트리플 | 참고 사항 | 연락처 |
|---|---|---|
| aarch64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
| aarch64-pc-windows-msvc | Steve Dower, Diego Russo, Chris Eibl | |
| wasm32-unknown-wasip1 | WASI SDK, Wasmtime | Brett Cannon, Michael Droettboom, Savannah Ostrowski |
| x86_64-apple-darwin | macOS, clang | Sam Gross, Barry Warsaw, Ronald Oussoren |
| x86_64-unknown-linux-gnu | glibc, clang | Victor Stinner, Gregory P. Smith |
Tier 3
- STATUS
- 신뢰할 수 있는 빌드봇을 갖추어야 합니다.
- 최소 한 명의 핵심 개발자가 해당 플랫폼을 지원하기로 등록되어 있어야 합니다.
- 실패에 대한 응답 SLA가 없습니다.
- 이러한 플랫폼에서의 실패는 릴리스를 막지 않습니다.
| Target Triple | Notes | Contacts |
|---|---|---|
| aarch64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| arm64-apple-ios | iOS on device | Russell Keith-Magee, Ned Deily |
| arm64-apple-ios-simulator | iOS on M1 macOS simulator | Russell Keith-Magee, Ned Deily |
| armv7l-unknown-linux-gnueabihf | 32-bit Raspberry Pi OS, gcc | Gregory P. Smith |
| aarch64-unknown-linux-gnu | 64-bit Raspberry Pi OS, gcc | Savannah Ostrowski, Stan Ulbrych |
| powerpc64le-unknown-linux-gnu | glibc, clang glibc, gcc |
Victor Stinner Victor Stinner |
| riscv64-unknown-linux-gnu | glibc, clang glibc, gcc |
Stan Ulbrych, Emma Smith Stan Ulbrych, Emma Smith |
| s390x-unknown-linux-gnu | glibc, gcc | Victor Stinner |
| wasm32-unknown-emscripten | emcc | Russell Keith-Magee |
| x86_64-linux-android | Russell Keith-Magee, Petr Viktorin | |
| x86_64-unknown-freebsd | BSD libc, clang | Victor Stinner |
지원되지 않는 플랫폼
위 등급에 나열되지 않은 모든 플랫폼은 핵심 팀에 의해 지원되지 않습니다. 핵심 팀은 그러한 플랫폼에서 개발 및 테스트를 수행하지 않으므로, Python이 해당 플랫폼에서 동작한다는 어떠한 보장도 제공할 수 없습니다.
그러나 코드베이스에는 지원되지 않는 코드, 즉 지원되지 않는 플랫폼에 특화된 코드가 포함되어 있습니다. 이 영역에 대한 기여는 다음 조건을 만족하는 한 환영합니다:
- 핵심 팀에 미치는 유지보수 부담이 최소한이어야 하며,
- 기여자 본인보다 상당히 더 많은 사람에게 이익이 되어야 합니다.
기여자는 수정/패치를 유지보수하고, 패치된 빌드를 테스트하고, 수정된 코드를 재배포하고, 자신의 사용자에게 약속을 하며, 그 밖에도 “자신의” 플랫폼을 지원할 수 있다고 가정합니다. 이를 염두에 두면, 지원되지 않는 수정 사항을 CPython의 유지보수 브랜치로 백포트할 필요는 일반적으로 없습니다.
유지보수 부담을 실제로 일으키거나 전반적인 개선을 방해하는 지원되지 않는 코드는 폐기 절차 없이 코드베이스에서 거부되거나 제거될 수 있습니다. 이를 의도적으로 수행하는 핵심 팀 구성원은 Python 개발자 가이드의 Ports and contacts list에 등재된 사람들에게 알리고, 제출된 수정 사항이 있다면(거슬리지 않는 경우) 검토하며, 우회 방법에 필요한 구성 또는 확장 기능 추가를 고려할 것을 권장합니다.
지원되지 않는 플랫폼에 관심 있는 사람들은 “자신의” 플랫폼과 관련된 문제를 통지받도록 요청하기 위해 Ports and contacts list에 자신을 추가할 수 있습니다. 그러나 반드시 통지를 받게 된다는 공식적인 보장은 없습니다.
이 PEP에 나열되지 않은 플랫폼도 더 넓은 Python 커뮤니티에 의해 다른 방식으로 지원될 수 있습니다. 원하는 플랫폼이 위에 나열되어 있지 않다면, 이미 누군가 어떤 형태로든 지원을 제공하고 있는지 온라인에서 검색해 보십시오.
참고
Microsoft Windows
Windows 10 이전 버전의 Windows는 Microsoft의 Fixed Lifecycle Policy를 따르며, 출시 후 5년간의 주류 지원 단계에서는 제품이 일반적으로 상업적으로 이용 가능하고, 추가로 5년간의 확장 지원 단계에서는 유료 지원이 여전히 제공되며 특정 버그 수정이 배포됩니다. Extended Security Updates (ESU)는 확장 지원이 종료된 후 특정 보안 업데이트를 받기 위한 “최후의 수단” 옵션으로 대량 구매 기업 고객에게 제공되는 유료 프로그램입니다. ESU는 확장 지원 만료 이후에 이어지는 별개의 단계로 간주됩니다.
Windows 10 이상은 Microsoft의 Modern Lifecycle Policy를 따르며, 이는 제품별, 버전별, 에디션별, 채널별로 다릅니다. 일반적으로 기능 업데이트(1709, 22H2)는 6~12개월마다 발생하며 18~36개월간 지원됩니다. Server 및 IoT 에디션과 LTSC 채널 릴리스는 5~10년간 지원되며, 주 버전(Windows 10, Windows 11)의 최신 기능 릴리스는 일반적으로 출시 후 최소 10년간 새 업데이트를 받습니다. Microsoft의 Windows Lifecycle FAQ에서 더 구체적이고 최신의 안내를 확인할 수 있습니다.
CPython의 Windows 지원은 현재 Microsoft의 수명 주기를 따릅니다. 새로운 기능 릴리스 X.Y.0은 확장 지원 단계가 아직 만료되지 않은 모든 Windows 버전을 지원합니다. 이후의 버그 수정 릴리스는 Microsoft에서 더 이상 지원하지 않더라도 원래 기능 릴리스와 동일한 Windows 버전을 지원합니다. CPython이 유지 관리 모드에 있는 동안 출시된 새로운 Windows 버전은 코어 팀과 릴리스 관리자의 재량에 따라 지원될 수 있습니다.
2024년 기준으로, Microsoft의 수명 주기에 대한 저희의 현재 해석은 IoT 및 임베디드 시스템용 Windows는 새로운 CPython 릴리스의 범위에서 제외된다는 것입니다. 이는 해당 제품군의 목적이 기능 업데이트를 피하는 데 있기 때문입니다. Windows Server는 보통 무료 보안 수정을 계속 받는 가장 오래된 버전이 될 것이며, 이는 동등한 API 버전을 가진 최초로 지원되는 클라이언트 릴리스를 결정하게 됩니다(이는 보통 수명 종료를 지난 상태일 것입니다).
각 기능 릴리스는 특정 버전의 Microsoft Visual Studio로 빌드됩니다. 해당 버전은 릴리스가 이루어질 당시 메인스트림 지원 상태여야 합니다. 확장 모듈 개발자는 일반적으로 동일한 Visual Studio 릴리스를 사용해야 합니다. 이들은 자신이 사용해야 하는 버전의 가용성과, 버전들의 종류를 작게 유지하는 것 모두에 관심을 두고 있습니다. CPython 소스 트리는 이전 Visual Studio 릴리스용으로 더 이상 유지 관리되지 않는 빌드 파일을 보존하며, 이에 대한 패치는 받아들여집니다. 이러한 빌드 파일은 해당 컴파일러의 확장 지원이 종료된 후 3년이 지나면 소스 트리에서 제거됩니다(다만 리비전 관리 시스템에는 계속 남아 있습니다).
POSIX
POSIX에 명시된 기능은 표준에 따라 동작할 것으로 기대됩니다. 이는 두 가지 방향으로 작용합니다:
- POSIX 기능을 사용할 수 있다면, 이는 POSIX를 준수할 것으로 기대됩니다.
명세를 벗어난 플랫폼에 대한 우회 방법은 허용됩니다. 지원되지 않는 플랫폼의 경우, 사소하지 않은 우회 방법보다는 기능을 비활성화하는 쪽이 선호됩니다.
- CPython은 POSIX에 명시된 범위를 넘어서는 POSIX 기능에 대해 어떠한 가정도 해서는 안 됩니다.
예를 들어, POSIX는
errno를 아무런 제약 없는int로 명시하고 있지만, 지원되는 모든 플랫폼에서 오류 코드는 우연히 양수입니다. 이에 의존하는 것은, 설사 지원되지 않는 플랫폼에서만 드러나는 문제라 하더라도 버그로 간주될 것입니다.
레거시 C 로케일
CPython 3.7.0부터, *nix 플랫폼은 레거시 C 로캘의 대안으로 C.UTF-8(전체 로캘), C.utf8(전체 로캘) 또는 UTF-8(LC_CTYPE전용 로캘) 중 적어도 하나를 제공할 것으로 예상됩니다.
레거시 C 로케일에서만 발생하고 적절히 구성된 비-ASCII 로케일에서는 재현되지 않는 유니코드 관련 통합 문제는 “수정하지 않음”으로 종료됩니다.
WASI
WASI 지원은 PEP 816에 정의되어 있습니다.
| Python | WASI | WASI SDK |
|---|---|---|
| 3.15 | 0.1 | 33 |
| 3.14 | 0.1 | 24 |
| 3.13 | 0.1 | 24 |
| 3.12 | 0.1 | 21 |
| 3.11 | 0.1 | 21 |
Python 3.15 이전의 모든 버전은 PEP 816보다 앞섭니다. 그 이전 버전들에 대한 버전 지원은 해당 PEP가 작성될 당시 지원되던 내용을 기준으로 합니다.
WASI는 Python 3.11과 3.12에서는 티어 3 플랫폼이었으며, Python 3.13부터 티어 2 플랫폼이 되었습니다.
WASI 0.2 지원은 시간 부족으로 건너뛰었으며, 그 대신 곧바로 WASI 0.3으로 가는 것이 더 낫다고 판단되었습니다. 이는 Bytecode Alliance의 권고에 근거한 것입니다.
WASI SDK 26과 27에는 특정 상황에서 CPython이 멈추게 만드는 버그가 있어, 이들은 건너뛰었습니다.
플랫폼 지원 중단
플랫폼이 계층화 지원에서 제외되는 경우, 해당 플랫폼이 더 이상 적극적으로 지원되지 않는다는 안내가 이 PEP에 게시되어야 합니다. 이 안내에는 다음이 포함되어야 합니다:
- 시스템의 이름,
- 이 플랫폼을 더 이상 지원하지 않는 최초의 릴리스 번호, 그리고
- 오래된 지원 코드가 실제로 제거되는 최초의 릴리스입니다.
어떤 경우에는 특정 코드가 사용되는 시스템의 구체적인 목록을 식별할 수 없습니다(예: 모든 지원 시스템에 존재한다고 간주되는 기능의 부재를 autoconf가 테스트하는 경우). 이 경우 이름은 지원되지 않게 될 정확한 조건(보통 전처리기 심볼)을 나타냅니다.
동시에, 누군가 이 플랫폼에 CPython을 설치하려고 하면 경고를 발생시키도록 CPython 빌드를 변경해야 합니다. autoconf를 사용하는 플랫폼에서는 configure도 지원되지 않는 플랫폼에 대한 경고를 발생시키도록 만들어야 합니다.
이는 해당 플랫폼의 잠재적 사용자들이 나서서 유지 관리를 맡을 기회를 제공합니다. Tier 3 지원을 잃은 플랫폼을 한 번도 지원된 적이 없는 플랫폼보다 더 나쁘게 취급하지 않습니다.
더 이상 지원되지 않는 플랫폼
- 이름: MS-DOS, MS-Windows 3.xUnsupported in: Python 2.0Code removed in: Python 2.1
- 이름: SunOS 4Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: DYNIXUnsupported in: Python 2.3Code removed in: Python 2.4
- 이름: dguxUnsupported in: Python 2.3Code removed in: Python 2.4
- 이름: MinixUnsupported in: Python 2.3Code removed in: Python 2.4
- 이름: Irix 4 및 –with-sgi-dlUnsupported in: Python 2.3Code removed in: Python 2.4
- Name: Linux 1Unsupported in: Python 2.3Code removed in: Python 2.4
- Name: __d6_pthread_create를 정의하는 시스템 (configure.in)Unsupported in: Python 2.3Code removed in: Python 2.4
- Name: thread_pthread.h에서 PY_PTHREAD_D4, PY_PTHREAD_D6, 또는 PY_PTHREAD_D7을 정의하는 시스템Unsupported in: Python 2.3Code removed in: Python 2.4
- Name: –with-dl-dld를 사용하는 시스템Unsupported in: Python 2.3Code removed in: Python 2.4
- Name: –without-universal-newlines를 사용하는 시스템,Unsupported in: Python 2.3Code removed in: Python 2.4
- Name: MacOS 9Unsupported in: Python 2.4Code removed in: Python 2.4
- Name: –with-wctype-functions를 사용하는 시스템Unsupported in: Python 2.6Code removed in: Python 2.6
- Name: Win9x, WinME, NT4Unsupported in: Python 2.6 (warning in 2.5 installer)Code removed in: Python 2.6
- Name: AtheOSUnsupported in: Python 2.6 (with “AtheOS” changed to “Syllable”)Build broken in: Python 2.7 (edit configure to re-enable)Code removed in: Python 3.0
- Name: BeOSUnsupported in: Python 2.6 (warning in configure)Build broken in: Python 2.7 (edit configure to re-enable)Code removed in: Python 3.0
- Name: Mach C 스레드를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- Name: SunOS 경량 프로세스(LWP)Unsupported in: Python 3.2Code removed in: Python 3.3
- Name: –with-pth(GNU pth 스레드)를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- Name: Irix 스레드를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- Name: OSF* 시스템 (issue 8606)Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: OS/2 (issue 16135)Unsupported in: Python 3.3Code removed in: Python 3.4
- 이름: VMS (issue 16136)Unsupported in: Python 3.3Code removed in: Python 3.4
- 이름: Windows 2000Unsupported in: Python 3.3Code removed in: Python 3.4
- 이름: COMSPEC가 command.com을 가리키는 Windows 시스템Unsupported in: Python 3.3Code removed in: Python 3.4
- 이름: RISC OSUnsupported in: Python 3.0 (some code actually removed)Code removed in: Python 3.4
- 이름: IRIXUnsupported in: Python 3.7Code removed in: Python 3.7
- 이름: 멀티스레딩을 지원하지 않는 시스템Unsupported in: Python 3.7Code removed in: Python 3.7
토론
- 2025년 11월: 지원되지 않는 플랫폼에 대한 정책 (Petr Viktorin)
- 2022년 4월: 계층화된 플랫폼 지원에 3단계 추가 고려 (Victor Stinner)
- 2022년 3월: 계층화된 플랫폼 지원 제안 (Brett Cannon)
- 2015년 2월: 플랫폼 지원 확보를 명확히 하기 위한 PEP 11 갱신 (Brett Cannon)
- 2014년 5월: 우리가 지원하는 플랫폼에 대한 공식 정책은 어디에 있는가? (Brett Cannon)
- 2007년 8월: PEP 11 갱신 - 포트 관리자 자원 요청 (Skip Montanaro)
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.