Python 3.15 정식 출시 - 지연 임포트, 불변 딕셔너리, UTF-8 기본 인코딩 도입

여러 오픈소스 Python 라이브러리를 관리하는 입장에서 새 Python 출시가 반가운 가장 큰 이유는 이전 버전의 지원 종료임. 이번에는 Python 3.10이 대상이므로, 지원 중인 모든 Python 버전과 호환되도록 관리하는 라이브러리에서도 드디어 Python 3.11 기능을 활용할 수 있게 됨. Python 3.11의 새로운 기능 문서를 참고하면 됨.

답답하게도 최신 Mac OS X와 Xcode로 업그레이드해도 기본 제공 버전은 Python 3.9.6임.
최신 Python 설치를 안내할 수는 있지만, 기본 버전을 그대로 쓰는 것보다 훨씬 번거로워짐. 어차피 uv 등으로 별도 버전을 설치하게 할 거라면 그냥 3.15를 설치하도록 하는 편이 나음.

기업용 배포판은 어차피 자체 Python을 10년간 지원함. Python에 LTS 릴리스가 없다 보니 대부분의 버전이 실제로는 의도보다 오래 살아남게 됨.
3.14는 Ubuntu 26.04, 3.12는 RHEL 10과 Ubuntu 24.04, 3.10은 Ubuntu 22.04, 3.9는 RHEL 9, 3.8은 Ubuntu 20.04, 3.6은 RHEL 8에 들어가며, RHEL 8의 지원 종료는 2029년임.

한편으로는 4년·4개 버전 뒤처지는 셈이지만, 다른 한편으로는 고작 그 정도의 차이임. 이런 접근이 마음에 들며, 이런 정책이 없으면 발전도 어려움. Google도 여러 곳에서 비슷한 정책을 적용함.

이렇게 해야 더 나은 기능을 누릴 수 있음. 테스트를 작성하고 Renovate로 패키지를 자동 업데이트하면서, 안전성은 그 테스트로 검증하면 됨.

3.10에서 깨지지 않는 범위에서 3.11을 활용한다면 괜찮음. 사용자로서는 3.10에 만족하며 계속 쓸 수도 있고, 시스템 제약 때문에 그 이상으로 올리지 못할 수도 있음.
HN에서는 인기 없는 견해겠지만, 새 버전이 나왔다는 이유로 기존 사용자의 호환성을 깨는 정책은 정말 싫음. 물론 기존 Python을 지원하는 옛 애플리케이션 버전을 계속 쓰는 선택지는 있음.

가장 주목하는 기능은 자유 스레딩 빌드용 abi3t 안정 ABI임. CPython 구현은 Petr Viktorin이 대부분 맡았고, 나는 생태계 지원을 준비하는 데 힘써 왔음. 보람차지만 꽤 어려운 작업이었고, beta1 출시 직전에는 Windows 전용 문제를 발견해 고치느라 밤늦게까지 작업하기도 함.
특히 cryptography가 Python 3.15 이상에서 플랫폼별로 단일 abi3.abi3t 휠을 배포하고 있다는 점이 뿌듯함. PyObject가 불투명 타입이어서 GIL 활성화 빌드와 자유 스레딩 빌드가 같은 휠을 사용할 수 있음.
올해 EuroPython에서 Python ABI와 abi3t 빌드·배포까지의 과정을 발표했으며, 영상에서 자세히 볼 수 있음.

현재 abi3를 사용하는 Python 모듈을 관리하고 있는데, PyUnstable_EnableTryIncRef()와 PyUnstable_TryIncRef() 같은 API를 제한 API에 포함할 계획이 있는지 궁금함. 기존에 사용하던 약한 참조 값 캐시를 구현하려면 지금까지는 이 API들이 필요했음. 관련 코드를 참고하면 됨.

pyo3의 abi3t 지원에 아직 구체적으로 남아 있는 문제가 있는지, 아니면 바로 사용해도 되는지 궁금함.

안정 ABI가 있으면 라이브러리의 자유 스레딩 빌드를 한 번만 만들어도 향후 적어도 몇 개의 Python 버전에서 계속 사용할 수 있음.

XZ 압축 소스 타르볼이 3.14보다 약 50% 커졌는데, 무슨 일이 있었는지 궁금함.
조금 살펴보니 전반적으로 조금씩 커진 것은 예상한 수준이지만, 문서 폴더에 총 10MB가 넘는 애니메이션 GIF 두 개가 추가되어 있음. XZ로도 크게 더 압축되지는 않을 듯하며, 새 샘플링 프로파일러로 보이는 “tachyon”을 시연함. 프로파일러 문서를 참고하면 됨.
터미널 세션 녹화라 TUI가 어떻게 생겼는지는 잘 보여주지만, 사용법을 배우는 데는 별로 유익하지 않아 보임. 정적인 화면 캡처를 바탕으로 한 SVG 도해가 훨씬 나았을 것 같음.

시간을 들여 SVG 도해를 직접 기여하면 서로에게 도움이 됨.

불편하게 들릴 수 있지만, 앞으로 살아남을 언어는 TypeScript·JavaScript, Rust, Python뿐이라고 봄. Python은 데이터 과학과 대화형 앱 때문에 남을 것 같음.
향후 10년 동안 AI 사용 여부와 관계없이 Rust로 다시 작성할 수 있는 것은 모두 Rust로 다시 작성될 것이라고 봄. 대표적으로 37signals 일부 백엔드의 Ruby→Rust 전환, Bun의 Zig→Rust 전환, 진행 중인 Git 전환, Mold 링커의 C→Rust 전환, Biome, TailwindCSS CLI 등을 들 수 있음. 내가 잘못 알고 있는 게 아니라면 Python 인터프리터도 Rust를 주 언어로 사용하는 방향으로 전환 중임. Rust 전환 목록도 참고할 만함.

C는 임베디드 프로세서에서 영원히 쓰일 것임.

언어와 생태계가 줄어드는 것도 좋겠지만, 이 프로그래밍 시스템들 중 어느 것도 아직 정점에 도달했다고 생각하지 않음. 혁신할 여지가 많으므로 통합보다는 더 다양한 방향으로 발전하는 편을 보고 싶음.

Python 인터프리터가 Rust로 전환 중이라는 데는 출처가 필요함. 제3자나 비공식적인 AI 기반 시도 외에, Python 핵심 팀이 CPython/Python에서 확실히 벗어나려 한다는 근거는 보지 못했음.

AI까지 언급했다면, 왜 곧바로 기계어, 즉 어셈블리나 바이너리로 가지 않는지 궁금함.

PEP 810의 명시적 지연 임포트가 드디어 도입되어 시작 시간을 줄일 수 있게 됨!

전역으로 활성화하지 않을 이유가 있는지 궁금함.

uvx --python 3.15 whatsnewt를 실행해 보니 재미있음.

PEP 798의 컴프리헨션 내 언패킹과 PEP 814의 내장 frozendict 타입이 드디어 도입됨. 오래전부터 원했던 소소한 편의성 개선이라 반가움.

실험적 JIT 컴파일러의 개선이 반가움. 기하평균 기준으로 x86-64 Linux에서는 표준 인터프리터 대비 78%, AArch64 macOS에서는 꼬리 호출 인터프리터 대비 1112% 빨라졌다고 함.