기본 콘텐츠로 건너뛰기

REPL Resize Fix

Python REPL에서 창 크기 바꾸면 화면이 깨질 때: CPython의 ‘리사이즈 이벤트’ 처리 방식이 바뀐 이유 meta_description: CPython PR #146459(gh-146458)는 Windows에서 콘솔 창 리사이즈 시 REPL의 높이/너비 추적이 틀어지는 문제를 수정했다. 핵심은 SIGWINCH 핸들러에서 즉시 크기를 갱신하던 방식을 바꾸고, refresh 단계에서 getheightwidth()로 화면 크기를 다시 계산하도록 만든 것이다. 이 글은 왜 이벤트 핸들러에서 상태를 미리 바꾸면 문제가 생기는지, pyrepl 기반 REPL에서 “resize” 이벤트가 어떻게 흘러가는지, 그리고 터미널 UI/CLI 도구를 만드는 개발자가 적용할 수 있는 실전 체크리스트를 정리한다. meta_keywords: python,repl,pyrepl,console,windows,resize,sigwinch,event queue,terminal ui,tty,refresh,rendering,bugfix,regression,test,mock,height,width meta_robots: index,follow REPL이나 터미널 기반 CLI를 만들다 보면, 은근히 사람을 미치게 하는 버그가 있다. 창 크기 바꾸면 화면이 깨짐 커서 위치가 튐 줄바꿈이 꼬여서 입력이 보이지 않음 특히 Windows 콘솔은 환경이 다양해서(기본 콘솔/Windows Terminal 등), “내 컴퓨터에서는 되는데” 가 자주 나온다. 최근 CPython에 들어간 PR #146459(gh-146458)는 딱 그 지점을 고쳤다. 콘솔 리사이즈에서 REPL의 height/width 추적이 틀어지는 문제 이번 글은 단순 ‘버그 픽스’ 소개가 아니라, 왜 이런 버그가 생기는지 터미널 UI를 만드는 입장에서 어떤 패턴이 안전한지 를 실무적으로 정리한다. 1) PR #146459가 바꾼 핵심: “리사이즈 이벤트...
최근 글

AArch64 JIT Relocation Fix

CPython AArch64 JIT 패치 노트 읽는 법: ‘관측되지 않은’ 버그라도 운영팀이 신경 써야 하는 이유 meta_description: CPython PR #148198(GH-146128)은 AArch64에서 JIT 코드의 상수 값이 부분적으로 손상될 수 있는 이론적 버그를 수정하기 위해, 문제 소지가 있던 “33rx” 릴로케이션 최적화(폴딩)를 제거했다. 관측 사례가 없어도 이런 패치가 중요한 이유(무증상 데이터 오염 가능성), 어떤 환경에서 의미가 커지는지(AArch64 + JIT 사용), 그리고 서비스 운영자가 지금 바로 할 수 있는 점검/롤백/테스트 체크리스트를 실무 관점에서 정리한다. meta_keywords: python,cpython,jit,aarch64,arm64,relocation,constant corruption,patch,stencil,optimizer,performance,stability,regression testing,release engineering,build,production,observability,risk meta_robots: index,follow 파이썬 릴리즈 노트나 PR을 보면 가끔 이런 문장이 나온다. “이 이슈는 theoretical이며, unmodified Python 인터프리터에서는 관측되지 않았다.” 대부분의 개발자는 여기서 스크롤을 내린다. “그럼 우리랑 상관 없겠네.” 근데 운영 관점에서는 오히려 반대로 읽는 게 맞다. 관측되지 않았다는 건, 관측이 어려운 종류 일 수도 있다 특히 이번 PR #148198(GH-146128)은 표현이 꽤 무섭다. AArch64 JIT 코드에서 상수 값이 “부분적으로 손상(partially corrupted)”될 수 있음 크래시가 아니라, 값이 조용히 틀어지는 유형은 재현이 어렵고 로그가 남기 힘들고 버그 티켓이 “가끔 결과가 이상함”으로 올라온다 그래서 이 글은 코어 구현 해설이 ...

Base64 Padding Policy in Python 3.15

Python 3.15의 base64 ‘패딩 옵션’이 반가운 이유: URL-safe 토큰/서명 검증에서 자주 깨지는 지점 정리 meta_description: CPython PR #147974(gh-73613)는 Python 3.15에서 base64/base32 인코딩·디코딩에 padded 옵션을 추가해, ‘=’ 패딩이 없는 입력도 더 명확하게 처리할 수 있게 했다. 이 글은 왜 패딩이 문제를 만드는지(웹 토큰, URL-safe, 로그/전달 과정의 손실), 어떤 함수가 어떻게 바뀌는지(padded 기본값/strict 모드와의 관계), 그리고 서비스 코드에서 안전하게 마이그레이션하는 체크리스트를 정리한다. meta_keywords: python,base64,binascii,base32,padding,urlsafe,token,encoding,decoding,validation,strict_mode,ignorechars,migration,backward compatibility,security,web,jwt,cookie,api,python 3.15 meta_robots: index,follow 운영하다 보면 base64는 “그냥 인코딩”이 아니다. 토큰 쿠키 URL 파라미터 서명/검증용 바이트 이런 데서 base64가 슬쩍 끼고, 그 순간부터 장애가 ‘간헐적’으로 보이기 시작한다. 특히 자주 깨지는 패턴이 이거다. 어떤 환경에서는 잘 디코딩되는데 어떤 환경에서는 Incorrect padding 류 에러가 난다 대부분 원인은 같다. ’=’ 패딩이 중간 전달 과정에서 잘리거나, 아예 없는 형태로 들어오기 때문 최근 CPython에 들어간 PR 하나가 이 문제를 꽤 깔끔하게 정리했다. CPython PR #147974 (gh-73613): Base32/Base64 without padding 지원 핵심은 새로운 옵션 한 단어다. padded= 이번...

Constant Folding Guardrails

CPython 옵티마이저가 “컨테이너는 건드리지 말자”로 돌아선 이유: 상수 폴딩(constant folding) 안정화 포인트 meta_description: CPython PR #148090(gh-148083)은 옵티마이저가 특정 연산을 “순수(pure) 평가”로 상수 폴딩할 때, 좌변/키가 컨테이너(list/dict/set 등)일 수 있는 경우엔 더 보수적으로 동작하도록 바꾼 패치다. 이 글은 왜 이런 변경이 필요한지(운영 관점), 어떤 코드에서 차이가 날 수 있는지(멤버십/서브스크립트/해시 가능성), 그리고 팀이 지금 당장 할 수 있는 실전 체크리스트(테스트/릴리즈 노트/성능 기대치 관리)를 정리한다. meta_keywords: python,cpython,optimizer,constant folding,bytecode,jit,profiling,performance,semantics,container,hashable,frozenset,frozendict,membership,guardrails,regression tests meta_robots: index,follow 파이썬 성능 얘기에서 “옵티마이저가 알아서 해주겠지”라는 말이 종종 나온다. 그런데 실무에서 진짜 중요한 건 성능 자체보다 예측 가능성 이다. 빨라졌는데 결과가 달라 보이면(혹은 예외 타이밍이 달라지면) 팀은 결국 그 최적화를 꺼버리거나 업그레이드를 미루게 된다 최근 CPython 쪽에 “최적화는 하되, 컨테이너는 조심하자”라는 톤의 패치가 하나 들어갔다. CPython PR #148090 (gh-148083) 요지: 좌변(lhs)이 컨테이너 타입일 수 있는 경우엔 상수 폴딩을 더 보수적으로 이 글은 코어 개발자용 해설이 아니라, 왜 이런 결정이 실무적으로 좋은지 어떤 코드에서 영향을 받을 수 있는지 팀이 업그레이드/테스트를 어떻게 가져가면 좋은지 를 정리한다. 1) 상수 폴딩(constant folding)은 “빨...

Zoneinfo Security Patch

CPython `_zoneinfo` 힙 버퍼 오버플로우 수정(gh-145883): “시간대 파싱은 라이브러리에게 맡기고, 우리는 업데이트를 자동화하자” meta_description: CPython은 PR #148087(gh-145883)로 _zoneinfo 에서 발견된 두 가지 heap-buffer-overflow를 수정했고(3.14 백포트), 테스트도 함께 보강했다. zoneinfo는 PEP 615 기반으로 시스템 tzdata 또는 PyPI tzdata를 사용하므로, 서비스는 ‘시간대 데이터+파서’ 조합을 안전하게 운영해야 한다. 이 글은 무엇이 바뀌었는지(개념), 운영자가 지금 당장 할 일(업데이트/검증/컨테이너/CI), 그리고 zoneinfo를 안전하게 쓰는 실전 체크리스트를 정리한다. meta_keywords: python,zoneinfo,security,heap-buffer-overflow,timezone,tzdata,iana,pep 615,cpython,patch,upgrade,container,linux,windows,validation,CI,dependency meta_robots: index,follow “시간대 처리는 늘 골치 아프다”는 말이 있다. 그런데 더 골치 아픈 건, 시간대는 그냥 기능 문제가 아니라 보안/안정성 문제로도 번진다는 점이다. 이번에 CPython 쪽에서 그걸 상징적으로 보여주는 변경이 하나 들어갔다. gh-145883: _zoneinfo 의 두 가지 heap-buffer-overflow 수정 CPython PR #148087 (3.14 백포트, merged 2026-04-04) 여기서 중요한 건 “내가 zoneinfo를 직접 건드릴 일이 있냐”가 아니다. 대부분의 서비스는 zoneinfo를 이렇게 쓴다. 사용자/외부 데이터에 들어있는 time zone을 읽고 서버에서 datetime을 만들고 저장/표시/정렬/스케줄링에 쓴다 즉, 입력이 엮이는 순간부터 운영 ...

Base64 Without Padding in Python 3.15

Python 3.15에서 Base64/32 패딩 없이도 더 잘 된다: “len%4==0” 지옥을 끝내는 실전 디코딩 패턴 meta_description: Base64/32 디코딩에서 가장 흔한 실수는 패딩(=) 누락 처리다. CPython은 PR #147974(gh-73613)로 Base32/Base64의 “패딩 없는 입력”을 더 잘 다루도록 개선했고, 문서/테스트도 함께 보강됐다(3.15 WhatsNew 포함). 이 글은 패딩이 왜 생기는지, 어디서 깨지는지, 그리고 지금 당장(3.11~) 안전하게 운영하는 호환 디코딩 함수까지 실전 관점으로 정리한다. meta_keywords: python,base64,base32,padding,urlsafe,decode,encoding,binascii,token,jwt,webhook,compat,python 3.15,whatsnew,security,validation,error handling meta_robots: index,follow Base64 디코딩하다가 한 번쯤은 이런 코드가 나왔을 거다. s += "=" * (-len(s) % 4) 문제는 이게 “잘 되는 것처럼 보이는데, 종종 사고를 만든다”는 점이다. 어떤 입력은 Base64가 아니라 그냥 쓰레기인데도 통과해버리고 어떤 입력은 URL-safe 변형인데 표준 Base64로 처리하다가 깨지고 어떤 입력은 패딩이 없어도 정상인 케이스인데, 서비스마다 처리가 달라진다 최근 CPython PR 하나가 이 불편함을 정확히 겨냥했다. gh-73613: Base32/Base64에서 패딩 없는 입력을 지원/개선 CPython PR #147974 (merged 2026-04-04) 이 글은 “새 기능 소개”보다, 운영에서 바로 쓰는 패턴 위주로 정리한다. 1) 패딩(=)은 왜 생기고, 왜 자꾸 빠지나 Base64는 3바이트를 4글자로 바꾼다. 그래서 입력 길이가 3의 배수가 아닐 때 ...

uv 0.11.3 Operations Notes

uv 0.11.3 실전 업그레이드 포인트: `uv audit` 무시 규칙부터 workspace metadata까지 meta_description: uv 0.11.3(2026-04-01)는 기능 ‘추가’보다 운영 품질을 올리는 릴리스다. uv audit 에 --ignore / --ignore-until-fixed 가 들어오고, uv workspace metadata 가 lock의 의존성 정보를 더 보여주며, wheel/ABI 관련 에러 메시지도 더 친절해졌다. 이 글은 팀 repo에서 uv를 올릴 때 바로 쓰는 체크리스트(20분)와 CI 적용 팁을 정리한다. meta_keywords: python,uv,packaging,dependency,lockfile,workspace,metadata,audit,security,vulnerability,ignore,CI,uv publish,hashing,abi3,free-threaded,wheel,error,PEP,release meta_robots: index,follow uv는 “빠른 패키지 도구”로만 보면 끝이다. 실무에서 uv가 진짜 가치가 있는 지점은, 의존성/빌드/배포를 한 덩어리로 운영 할 때다. 그래서 uv 업그레이드는 릴리스 노트 한 줄 때문에 CI가 깨지는지(혹은 더 좋아지는지)를 바로 드러낸다. 이번 uv 0.11.3(Released 2026-04-01)는 큰 기능 쇼케이스보다, 운영 쪽에서 자주 부딪히는 포인트를 정리해 준 릴리스다. uv audit 에 --ignore 와 --ignore-until-fixed 추가(프리뷰) uv publish 에서 해시 계산 단계에 진행바 추가 uv workspace metadata 가 lock의 의존성 정보를 더 보여주도록 확장 빌드된 wheel 에러에서 플랫폼/ABI 관련 메시지가 더 읽히게 개선 이 글은 “릴리스 요약”이 아니라, 레포에서 안전하게 올리는 순서 로 정리한다. 1) 결론: 0.11.3은 ‘보...