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 코어 팀이 어떤 플랫폼을 지원 대상으로 간주하는 데 필요한 요건을 규정하고, CPython 사용자가 거의 또는 전혀 없는 플랫폼의 코드를 제거하는 절차도 제시합니다.
반면에 이러한 코드 조각을 메인 저장소에 허용하면 협업을 촉진하고, 코드 베이스에서 이식성이 없는 부분을 찾아내는 데 도움이 되며, “새로운” 플랫폼에 대한 지원을 처음 구축하는 데에도 필요합니다. 이 PEP는 플랫폼이 “지원되지 않는다”는 것이 무엇을 의미하는지, 그리고 코어 팀이 그러한 플랫폼의 코드를 어떻게 다루는지 규정합니다.
이 PEP는 또한 CPython 개발 팀이 직접 지원하는 플랫폼이 무엇인지 명시적으로 나열합니다.
지원 등급
플랫폼 지원은 여러 등급으로 나뉩니다. 등급마다 요건이 다르며, 그에 따라 지원에 대한 약속도 달라집니다.
어떤 등급으로 승격하려면 운영 위원회의 지지가 필요하며, 이는 팀의 합의에 따라 이루어질 것으로 기대됩니다. 어떤 플랫폼이 현재 등급의 요건을 장기간 충족하지 못하면 릴리스 관리자나 운영 위원회의 판단에 따라 하위 등급으로 강등됩니다. 새로운 기능 릴리스의 b1까지 어떤 등급의 요건도 더 이상 충족하지 못하는 플랫폼에 대해서는, 해당 플랫폼의 지원이 곧 제거될 예정임을 커뮤니티에 알리는 공지를 합니다(예: b1 공지에서). 첫 번째 릴리스 후보까지 해당 플랫폼이 최소한 한 등급의 요건을 충족하도록 조치되지 않으면, 이 PEP에 지원되지 않는 플랫폼으로 등재됩니다.
1등급
- 상태
- 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 |
티어 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 |
티어 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로 빌드됩니다. 해당 버전은 릴리스 시점에 메인스트림 지원(mainstream support)을 받고 있어야 합니다. 확장 모듈 개발자는 일반적으로 같은 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 로케일에서는 재현되지 않는 유니코드 관련 통합 문제는 모두 “won’t fix”(수정하지 않음)로 종료됩니다.
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도 지원되지 않는 플랫폼이라는 경고를 출력하도록 해야 합니다.
이를 통해 해당 플랫폼의 잠재적 사용자에게 직접 나서서 유지 보수를 맡겠다고 제안할 기회가 주어집니다. 티어 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
- 이름: Linux 1Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: __d6_pthread_create를 정의하는 시스템 (configure.in)Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: thread_pthread.h에서 PY_PTHREAD_D4, PY_PTHREAD_D6, 또는 PY_PTHREAD_D7을 정의하는 시스템Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: –with-dl-dld를 사용하는 시스템Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: –without-universal-newlines(범용 줄바꿈 비활성화)를 사용하는 시스템,Unsupported in: Python 2.3Code removed in: Python 2.4
- 이름: MacOS 9Unsupported in: Python 2.4Code removed in: Python 2.4
- 이름: –with-wctype-functions(wctype 함수 사용)를 사용하는 시스템Unsupported in: Python 2.6Code removed in: Python 2.6
- 이름: Win9x, WinME, NT4Unsupported in: Python 2.6 (warning in 2.5 installer)Code removed in: Python 2.6
- 이름: 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
- 이름: 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
- 이름: Mach C 스레드를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: SunOS 경량 프로세스(LWP)Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: –with-pth(GNU pth 스레드)를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: Irix 스레드를 사용하는 시스템Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: OSF* 시스템 (이슈 8606)Unsupported in: Python 3.2Code removed in: Python 3.3
- 이름: OS/2 (이슈 16135)Unsupported in: Python 3.3Code removed in: Python 3.4
- 이름: VMS (이슈 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.