If Dev Then ?

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가 바꾼 핵심: “리사이즈 이벤트...

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)”될 수 있음 크래시가 아니라, 값이 조용히 틀어지는 유형은 재현이 어렵고 로그가 남기 힘들고 버그 티켓이 “가끔 결과가 이상함”으로 올라온다 그래서 이 글은 코어 구현 해설이 ...

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= 이번...

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)은 “빨...

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을 만들고 저장/표시/정렬/스케줄링에 쓴다 즉, 입력이 엮이는 순간부터 운영 ...

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 실전 업그레이드 포인트: `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은 ‘보...

Ruff 0.15.9에서 ‘조용히’ 바뀐 것들: 린트/포맷 업그레이드 안전하게 하는 체크리스트 meta_description: Ruff 0.15.9(2026-04-02)는 큰 기능 추가보다 규칙/수정 안전성/포맷 옵션 같은 ‘업그레이드 때 사고 나는 지점’을 건드린 릴리스다. 이 글은 실제 프로젝트에서 ruff를 올릴 때 바로 쓰는 20분 체크리스트(잠금/preview 분리/unsafe fix 관리/노트북 W391/새 포맷 옵션)와 CI 적용 팁을 정리한다. meta_keywords: python,ruff,lint,formatter,format,pyflakes,pyupgrade,pycodestyle,preview,unsafe fix,CI,pre-commit,notebook,W391,F811,RUF010,nested-string-quote-style,UP012,UP018,SIM105 meta_robots: index,follow Ruff 업그레이드는 대개 “버전만 올리고 끝”이 아니다. 특히 팀/CI가 붙어 있는 프로젝트에서는, 릴리스 노트의 한 줄이 곧바로 빨간불(빌드 실패) 로 바뀐다. 이번 Ruff 0.15.9(2026-04-02)는 겉으로는 조용한 패치 릴리스처럼 보이는데, 실제로는 업그레이드 때 사고 나는 포인트 를 몇 군데 건드렸다. (preview) 타입 힌트가 붙은 변수 재선언을 F811 로 잡기 시작 fix의 안전성(unsafe) 표기 강화 ( RUF010 ) 노트북 셀에서의 W391 fix 동작 조정 포매터 옵션 추가: nested-string-quote-style 이 글은 “릴리스 노트 요약”이 아니라, 프로젝트에서 안전하게 올리는 순서 로 정리한다. 1) 먼저 결론: 0.15.9 업그레이드는 ‘preview 분리’가 핵심 0.15.9에서 가장 실무적으로 체감 큰 변화는 “preview 모드에서 규칙이 조금 더 까다로워질 수 있다”는 점이다. 대표적으로 릴리스 노트에 있는 이 항...

CPython: 재귀(RecursionError) 보호가 더 ‘실제 스택 포인터’ 기반으로 정교해졌다 — 왜 중요하냐면 meta_description: CPython이 _Py_get_machine_stack_pointer()를 “진짜 머신 스택 포인터(sp/rsp)”로 반환하도록 바꾸면서, 재귀 한계/스택 오버플로 보호 로직이 더 일관되게 동작하도록 개선됐다(GH-126910). 이 글은 어떤 문제가 있었는지(프레임 주소 vs 스택 포인터, 스택 전환 코너 케이스), 무엇이 바뀌었는지(soft/hard limit 체크 정리), 그리고 임베딩/샌드박스/깊은 파서 입력처럼 재귀가 자주 터지는 실무 환경에서 어떤 이득이 있는지 설명한다. meta_keywords: python,cpython,recursion,RecursionError,stack pointer,_Py_get_machine_stack_pointer,stack overflow,soft limit,hard limit,Py_FatalError,sanitizers,UBSan,embedding,parser,xml,security,robustness,debugging,limits meta_robots: index,follow 재귀 제한은 파이썬에서 흔히 “그냥 RecursionError 뜨는 거”로만 보이지만, CPython 입장에서는 꽤 민감한 영역이다. 너무 늦게 막으면: C 스택을 진짜로 넘어서 프로세스 크래시 로 간다 너무 일찍 막으면: 정상적인 입력/코드도 쓸데없이 RecursionError 가 난다 예외를 던지는 순간에도 스택이 충분히 남아 있어야 한다(안 그러면 예외 처리 중에 또 터진다) 이번 CPython PR(GH-126910)은 이 방어선을 한 단계 더 “하드웨어에 가깝게” 정리한다. 핵심만 말하면: _Py_get_machine_stack_pointer() 가 이제 “프레임 주소 비슷한 값”이 아니라 실제 스택 포인터(sp/rsp) 를 읽어서 반환...

CPython: bytes.hex(bytes_per_sep) 허용 범위가 커졌다 — sys.maxsize도 이제 OK(gh-147944) meta_description: Python 3.15에서 bytes.hex/bytearray.hex/memoryview.hex 및 binascii.b2a_hex의 bytes_per_sep 인자 허용 범위가 확대되어 sys.maxsize와 -sys.maxsize가 유효해졌다(gh-147944). 겉보기엔 테스트 한 줄 바뀐 수준이지만, 실제로는 Argument Clinic 변환(int→Py_ssize_t)과 정수 변환 경로가 정리되면서 “경계값에서의 Overflow/TypeError”가 더 일관되게 동작한다. 이 글은 무엇이 바뀌었는지, 실무에서 어디에 도움이 되는지(로그/헥스 덤프/프로토콜 디버깅), 그리고 안전한 사용 패턴을 정리한다. meta_keywords: python,bytes,bytearray,memoryview,hex,bytes_per_sep,binascii,b2a_hex,Py_ssize_t,sys.maxsize,OverflowError,Argument Clinic,debugging,hexdump,logging,protocol,binary,호환성,경계값,테스트 meta_robots: index,follow 바이너리 로그를 남기거나(패킷/토큰/압축 데이터), 디버깅용으로 bytes.hex() 를 쓰다 보면 이런 걸 해본 적이 있을 거다. “너무 길어서 보기 힘드니, 구분자(sep)를 넣어서 그룹으로 끊자” 예: payload.hex(':', 2) # b9:01ef 처럼 2바이트마다 구분 payload.hex(' ', -2) # 반대 방향(왼쪽부터)으로 2바이트마다 이때 bytes_per_sep 에 “엄청 큰 값”을 넣으면, 사실상 구분자를 넣지 않는 효과가 난다. bytes_per_sep 가 길이보다 크면 → 구분자 없음 그런데 C...

CPython: 이제 bytes.replace()의 count를 키워드로 쓸 수 있다 — 그런데 이 변화가 실무에 주는 이득은? meta_description: CPython에서 bytes.replace()/bytearray.replace()의 count 인자가 키워드 인자로도 지원된다(gh-147856). 겉보기엔 사소한 문법 변화지만, 래퍼 함수/타입 힌트/리팩터링 안정성, 그리고 바이너리 프로토콜 처리 코드의 가독성에 꽤 도움이 된다. 이 글은 무엇이 바뀌었는지, 기존 코드와 호환성은 어떤지, 실무에서 어떻게 써야 이득이 되는지(예시 포함) 정리한다. meta_keywords: python,bytes,bytearray,replace,count,keyword argument,stdlib,cpython,argument clinic,METH_KEYWORDS,refactor,typing,protocol,binary,text processing,호환성,가독성,리팩터링,테스트 meta_robots: index,follow 파이썬 표준 라이브러리/빌트인에 들어가는 변화는 가끔 ‘한 줄짜리 편의’처럼 보이는데, 실제로는 코드베이스 전체의 유지보수 비용을 조금씩 깎는 역할을 한다. 이번 CPython PR(gh-147856)이 딱 그 케이스다. 이제 bytes.replace() 와 bytearray.replace() 에서 count 를 키워드 인자 로 줄 수 있다. 예전에는 이렇게만 됐다. b"aa".replace(b"a", b"b", 1) 이제는 이렇게도 된다. b"aa".replace(b"a", b"b", count=1) “그래서 뭐?” 싶을 수 있는데, 실무에서 특히 바이너리 처리 코드 를 많이 만지는 팀에겐 의외로 이득이 있다. 1) 정확히 무엇이 바뀌었나: 시그니처가 ‘positional-only...