Planet Python 한국어 노트

Planet Python 한국어

Planet Python 웹사이트는 다양한 소스에서 파이썬 관련 콘텐츠를 집계하는 행성 사이트입니다. 블로그, 뉴스 사이트, 기타 온라인 출판물이 포함됩니다. 이 사이트는 파이썬 프로그래밍 세계의 최신 개발을 추적하는 데 있어 한 곳에서 모든 정보를 얻을 수 있는 장소입니다. 사이트의 콘텐츠에는 튜토리얼, 뉴스, 프로젝트 발표, 파이썬 관련 다양한 주제에 대한 논의가 포함됩니다. 사용자는 파이썬 커뮤니티, 새로운 릴리즈, 콘퍼런스, 파이썬 프로그래밍 언어 사용의 베스트 프랙티스에 대해 정보를 얻을 수 있습니다. 이 웹사이트의 목적은 파이썬 관련 콘텐츠를 홍보하고 전파하여 파이썬 커뮤니티의 성장과 발전을 기여하는 것입니다.

노트 스레드

직장에서의 분노는 일반적으로 비생산적이며 동료들에게 부정적인 환경을 조성합니다. 회사 내에서 공유된 비전을 발견하고 이에 동의하거나, 의견 불일치가 존재하고 변화가 불가능할 경우 이를 받아들이는 것이 중요합니다. 기술 산업에서 널리 제기되는 질문은 급격한 변화, 특히 AI와 관련하여 분노를 피하는 방법입니다. 저자는 분노보다는 혼란과 불안감을 느끼는 것이 더 적절한 반응이라고 제안합니다. 불안은 비난을 가하지 않고 미래에 대한 불확실성을 인정합니다. 그러나 분노는 대상이 필요하며 외부의 잘못을 암시합니다. AI가 생산성 향상을 가져올 수 있지만, 이러한 이익이 직원보다 회사를 더 많이 이롭게 할 것이라는 우려가 있습니다. 많은 기술 리더들은 비용과 대규모 AI 연구소와의 경쟁에 대한 걱정으로 AI에 대해 의구심을 표합니다. 저자는 분노 대신 불확실성을 받아들이는 것을 제안하며, 이는 새로운 발전에 대한 호기심과 참여를 촉진할 수 있습니다. 진정한 흥분은 또 다른 대안이며, 권한 부여와 자유의 느낌으로 이어집니다. 저자는 AI의 이점이 회사 이익뿐만 아니라 개인 프로젝트에서도 종종 발견된다고 언급합니다. 이러한 변화는 리더들이 직면한 불확실성을 강조하며, 많은 리더들이 개인적인 의구심에도 불구하고 자신감을 내비칩니다. 저자는 자신의 직업과 사업에 대한 흥분과 불확실성의 이중성을 경험합니다. 분노는 악당을 제공함으로써 더 실행 가능하게 느껴질 수 있지만, AI와 같은 파괴적인 변화 중에 초점을 잘못 돌리는 경우가 많습니다. 이러한 변화의 사회적, 환경적, 세계적 영향은 우려스럽지만, 개인에 대한 분노에 집착하는 것은 비생산적입니다. 대신, 실험에 대한 호기심과 흥분을 유지하는 것이 권장됩니다. 이 접근 방식은 저항이 진정으로 정당화될 때와 어디에서 정당화될지에 대한 정보에 입각한 결정을 내릴 수 있도록 할 것입니다.
저자는 휴식기 이후 블로그 게시물을 따라잡고 있습니다. 최근 FOSS4G UK 2026에서 발표가 수락되어 FOSS4G UK 2025에서 진행했던 워크숍에 대해 글을 쓰게 되었습니다. 워크숍은 pg_tileserv 도구를 사용하여 PostGIS 데이터베이스에서 실시간 벡터 타일을 생성하는 데 중점을 두었습니다. 참가자들은 테이블과 PostGIS 함수에서 직접 타일을 제공하는 방법을 배웠으며, 실습 과제가 제공되었습니다. 워크숍은 복잡한 지리 공간 워크플로우를 위한 실시간 벡터 타일 생성의 힘을 보여주는 것을 목표로 했습니다.별도로, 저자는 Electromagnetic Field 페스티벌에서 "Lights, Spectrometer, Action!"이라는 제목의 발표를 했습니다. 이 발표는 분광계(spectrometer)를 이용한 실시간 시연을 포함하여 분광학의 과학을 탐구했습니다. 다양한 광원의 빛과 다양한 물질과의 상호 작용을 조사했습니다. 발표는 또한 분광학의 위성 영상 응용 및 화학에서의 잠재적 사용에 대해서도 다루었습니다.앞으로 저자는 환경청 DEM 데이터를 접근 가능하게 만드는 것에 대해 FOSS4G UK 2026에서 발표할 예정입니다. 이 데이터는 STAC 및 COG와 같은 클라우드 네이티브 형식으로 변환되어 접근 및 분석을 용이하게 했습니다. 이 작업은 DEM 모자이크 및 사용자 정의 웹 맵 시각화를 효율적으로 생성할 수 있게 합니다. 저자는 또한 분광계 제어를 위한 사용자 정의 소프트웨어를 개발하고 있습니다.
CdXz5zHNQW_3HN87m7Gll.png
LLM의 부상은 프로그래밍 프로세스를 크게 간소화하여 개발자에게 언어 선택의 중요성을 덜어주었습니다. 다른 언어로 코드를 다시 작성하거나 익숙하지 않은 언어로 코드를 생성하는 능력은 인간의 마찰을 줄여줍니다. 이러한 변화로 인해 언어 선택은 성능과 같은 마케팅 및 인식된 이점에 의해 더 많이 좌우될 수 있습니다. 예를 들어, Rust는 더 빠른 소프트웨어에 대한 욕구 증가와 LLM의 효율적인 코드 최적화 능력 덕분에 채택이 증가했습니다. 성능에 중점을 두는 것으로 알려진 Mitchell Hashimoto와 같은 전문가들도 에이전트가 작성한 코드를 수용하고 있습니다. autoresearch와 같은 도구를 통해 개발자는 광범위한 사전 지식 없이도 최적화를 달성할 수 있습니다.Rust 외에도 Zig와 같은 다른 "어려운 언어"도 속도와 작은 풋프린트를 목표로 하는 프로젝트에서 인기를 얻고 있습니다. Zig를 활용하는 Cloudflare의 Artifacts 서비스와 Vercel의 fx agent는 종종 LLM의 지원을 받아 이러한 추세를 보여줍니다. 또한 개발자들은 DWARF 파일, eBPF, 사용자 지정 네트워크 드라이버, 심지어 오래된 컴퓨팅 하드웨어와 같은 전통적으로 어려운 기술을 다루고 있습니다. 이러한 영역 중 상당수는 이전에 접근할 수 없었거나 의도적으로 접근이 제한되었습니다. 이러한 변화가 일부 "슬로프(slop)"를 야기할 수 있지만, 속도와 효율성을 중시하는 더 많은 개발자를 참여시켜 고성능 소프트웨어의 새로운 시대를 열 수 있습니다.
Django의 signing 모듈은 사용자 로그인이나 세션 없이도 안전한 구독 취소 링크를 제공합니다. URL에 사용자 ID를 직접 사용하는 안전하지 않은 방식은 대량 구독 취소에 취약합니다. 데이터베이스에 임의의 토큰을 저장하는 것은 일반적이지만 더 복잡한 해결책입니다. Django의 django.core.signing 모듈은 SECRET_KEY로 값(예: 사용자의 기본 키)을 서명함으로써 데이터베이스 저장 없이도 변조 방지 토큰을 제공합니다."salt"는 다른 기능 간의 토큰 충돌을 방지하는 데 중요하며, 한 목적(예: 공지)을 위한 토큰이 다른 목적(예: 포럼 알림)에 사용될 수 없도록 보장합니다. 서명된 토큰은 비밀이 아니며, 내부 데이터는 읽을 수 있지만 서명을 무효화하지 않고는 변경할 수 없습니다. 따라서 숨겨져야 하는 민감한 정보는 서명하지 마십시오.중요하게도, 메일 스캐너와 프리페처가 의도치 않게 사용자를 구독 취소하는 것을 방지하기 위해 구독 취소 작업은 GET 요청이 아닌 POST 요청에서 이루어져야 합니다. GET에서 확인 페이지를 표시하고, POST로 작업을 완료하는 것이 권장되는 흐름입니다.구독 취소 토큰은 오래된 링크를 두 번 클릭해도 동일하게 안전한 결과가 나오므로 만료가 필요하지 않은 경우가 많습니다. 그러나 마법 로그인 링크와 같은 민감한 작업의 경우, signing.loadsmax_age 인수는 데이터베이스 저장 없이 만료를 제공합니다. 이메일 인증과 같은 단일 사용 토큰 시나리오의 경우, 서명만으로는 사용을 추적할 수 없으므로 추가적인 상태 관리(사용된 토큰의 데이터베이스 기록)가 필요합니다.
CdXz5zHNQW_kaNMCAHtWT.webp
최근 설문 조사에 따르면 AI는 대부분의 개발자 워크플로우에 필수적이며, 90%가 매주 또는 매일 AI를 사용하고 있습니다. AI는 코드를 빠르게 작성할 수 있지만, 개발자는 AI가 생성한 결과물을 이해하고 평가하며 승인할 책임을 여전히 가지고 있습니다. 이는 IDE의 중요한 역할을 강조하며, PyCharm은 개발자 제어를 강화하는 도구로 부각됩니다. PyCharm은 사용자가 선호하는 AI 에이전트와 모델을 선택할 수 있도록 하며, 주요 옵션에 대한 네이티브 지원과 더 많은 옵션을 위한 광범위한 레지스트리를 제공합니다. 사용자는 JetBrains AI 구독을 선택하거나 Ollama 또는 LM Studio를 통한 로컬 모델을 포함한 자체 도구를 활용할 수 있습니다. IDE는 또한 재사용 가능한 "Skills"를 통해 특정 프로젝트 규칙 및 코딩 표준에 AI 에이전트를 훈련시킬 수 있도록 개발자에게 권한을 부여합니다. PyCharm은 최신 기능을 포함하여 Django에 대한 강력하고 버전별 지원을 제공하여 AI 훈련 데이터가 오래되었더라도 일관성을 보장합니다. 또한 IDE는 시각적 diff 및 통합 Git 기록과 같은 코드 검토를 위한 포괄적인 도구를 제공하며, 버전 제어와 독립적으로 변경 사항을 추적하기 위한 로컬 기록 기능도 제공합니다. PyCharm의 Django Logical Structure 뷰는 프레임워크 관점에서 애플리케이션 아키텍처를 시각화하여 이해를 돕습니다. 마지막으로, Endpoints 도구 창과 데이터 편집기/뷰어는 API 검증 및 데이터베이스 상호 작용을 용이하게 하여 개발자가 AI 생성 코드와 그 영향을 자신 있게 평가할 수 있도록 합니다.
대규모 언어 모델(LLM)은 특히 코드 검토량과 관련하여 오픈 소스 소프트웨어 커뮤니티 내 기존 위기를 악화시키고 있습니다. 이러한 압력은 오픈 소스를 넘어 컴퓨팅 분야 전체에 영향을 미칩니다. LLM은 이를 피하려는 사람들에게조차 프로그래밍 방식을 근본적으로 변화시키고 있습니다. 사용자들은 LLM을 사용하여 광범위한 코드 검토를 자동화하고 있으며, 이는 상당한 컴퓨팅 비용을 발생시킵니다.이러한 자동화는 이전에는 더 쉽게 접근 가능했던 것에 대해 요금을 부과하는 API 가격 변경 가능성에 대한 우려를 제기합니다. 무료 및 오픈 소스 소프트웨어의 지지자인 저자는 과거 컴파일러와 같은 도구를 얻는 것이 상당한 비용이었던 시대를 반영하여 소프트웨어를 임대하는 방향으로의 전환을 관찰합니다. 이제 많은 소프트웨어 도구와 LLM 액세스에는 지속적인 월별 지불이 필요하며, 이는 개발자가 작업을 완료하기 위해 비용을 지불해야 하는 상황으로 이어집니다.이러한 추세는 기업이 도난당한 작업으로 모델을 훈련한 다음 개발자에게 다시 판매하는 "enshitification"으로 간주됩니다. 더욱이 LLM은 엔지니어링 일자리에 대한 위협으로 제시되며, 기회가 줄어들고 임금이 낮아지는 악화되는 노동 시장에 기여합니다. 기술 기업은 자신이 통제하는 모델의 사용을 추진함으로써 엔지니어링 직업을 적극적으로 공격하는 것으로 인식됩니다.LLM 사용이 의무화되지 않더라도 LLM 생성 작업에 뒤처지지 않으려는 압력은 엄청나며 공급망 보안을 위태롭게 할 수 있습니다. 저자는 LLM 과대광고가 노동자와 환경에 대한 더 광범위한 사회적 공격의 일부라고 주장합니다. 이를 해결하려면 개별적인 적응이 아닌 집단적인 정치적, 사회적 행동이 필요합니다.
PyCharm 2026.2는 Python 코드 인사이트 향상에 초점을 맞춘 263개의 수정 사항과 개선 사항을 도입합니다. 주요 업데이트에는 향상된 타입 추론, 오탐 감소, 보다 안정적인 리팩토링이 포함됩니다. 이번 릴리스는 SQLAlchemy 2.0에 대한 지원을 개선하여 이전에 문제가 되었던 수많은 시나리오를 해결합니다. 코드 인사이트는 제어 흐름 축소 및 도달 불가능한 코드 처리의 수정 사항으로 이점을 얻습니다. 타입 어노테이션 내의 문자열과 이터러블 언패킹은 이제 더 정확한 분석을 볼 수 있습니다. 증강 할당 및 생성자 반환 타입도 더 정확하게 분석됩니다. Enum 멤버는 이제 값 및 이름 속성에 대해 Literal 타입을 반환합니다. 매개변수 타입은 이제 데코레이터에서 추론되며, 완료 및 자동 가져오기가 더 스마트해졌습니다. PyCharm은 이제 기존 가져오기 재사용을 우선시하며 중첩 클래스의 자동 가져오기를 지원합니다. unittest.mock.patch 대상에 대한 완료가 이제 작동하며, 내장 메서드를 재정의하면 완전한 주석이 달린 시그니처가 채워집니다. 타입 인레이 힌트는 추론된 타입 인수를 인라인으로 표시하며, f-string 형식 사양 유효성 검사가 확장되었습니다. 이름 바꾸기 리팩토링은 이제 모듈 참조를 올바르게 업데이트하며, 필드 리팩토링은 이제 속성으로 명명됩니다. 전반적으로 이러한 개선 사항은 PyCharm 내에서 Python 코드에 대한 보다 정확하고 예측 가능한 이해로 이어집니다.
최근 한 논문에서 폐쇄형 가중치 모델에서 추론 흔적을 추출하는 방법을 공개하여 온라인 토론을 촉발했습니다. 추론 흔적은 일반적으로 사용자에게 숨겨져 있으며, 이는 공개형 가중치 모델에서 볼 수 있는 것과 다릅니다. 이러한 흔적은 본질적으로 모델이 최종 답변 전에 스크래치패드에 출력하도록 훈련된 텍스트입니다. 특수 토큰이 이러한 추론 섹션을 구분하며, 파서는 이 콘텐츠를 별도의 스트림으로 보냅니다. 폐쇄형 모델의 경우, 이 중간 텍스트는 편집되거나 요약될 가능성이 높습니다. 모델이 수행하는 추론의 양은 샘플링이 아닌 시스템 프롬프트에 의해 결정됩니다. 예를 들어, "낮음" 또는 "지름길 허용 안 함, 절대 최대치"로 설정될 수 있습니다. 모델은 이 스크래치 작업을 최종 응답 채널과 분리하도록 훈련됩니다. 모델을 속여 추론 채널 내에 있다고 믿게 하면 이러한 흔적이 유출될 수 있습니다. 사고가 비활성화된 이전 모델은 때때로 자신의 생각을 null 장치에 기록했습니다. 일부 경우에는 모델의 유일한 특별한 행동이 사고를 자제하는 능력입니다. 이는 모델의 일반적인 사고 메커니즘을 비활성화하여 달성할 수 있습니다. 일부 추론 API는 추론을 관리하기 위해 토큰을 미리 채울 수 있으며, 이는 사용자 지정 도구로 우회할 수 있으며, 특히 네이티브 추론이 비활성화된 경우에 그렇습니다. 저자는 이 블로그 게시물 자체의 문법 검사를 위해 특정 모델을 사용하려고 시도하는 동안 유머러스하게 콘텐츠 필터를 만났습니다.
CdXz5zHNQW_KvYYV2hcVr.png
Python 3.12.14, 3.11.16, 및 3.10.21이 보안 수정 전용 업데이트로 릴리스되었습니다. 이 릴리스는 tarfile 강화, 경로 탐색 우회, Python 표준 라이브러리와 관련된 다양한 CVE를 포함한 여러 심각한 취약점을 해결합니다. 특히 신뢰할 수 없는 tarball을 처리하는 이 버전의 사용자는 업데이트하는 것이 좋습니다.AI에 의해 주로 생성된 프로젝트에 대한 Codeberg의 최근 금지가 GitHub 대안으로서의 함의에 대해 검토되고 있습니다. 이 정책은 코드 호스팅 플랫폼이 소프트웨어의 동작 및 영향에 초점을 맞추는 대신 소프트웨어 생성 프로세스를 규제해야 하는지에 대한 질문을 제기합니다. "대부분 생성된" 코드를 정의하고 시행하는 어려움은 이 접근 방식에 상당한 과제를 안겨줍니다.Brett Cannon은 PyPI에서 재현 가능한 빌드를 달성하기 위한 누락된 구성 요소를 강조했습니다. 현재 배포판이 시작된 정확한 소스 코드 또는 사용된 특정 빌드 도구를 기록하는 표준화된 방법이 없습니다. 이러한 격차에 대한 해결책을 구현하려면 sdist 메타데이터를 수정하고 잠재적으로 sdist 버전 2를 도입해야 합니다.재현 가능한 빌드의 주요 초점은 소프트웨어 공급망의 무결성을 보장하는 것입니다. 목표는 생성자가 재현을 원활한 프로세스로 만들면서 빌드 백엔드 및 설치 프로그램에 필요한 정보를 제공하는 것입니다. 이를 통해 PyPI는 독립적으로 재현된 빌드를 표시하여 사용자에게 향상된 신뢰를 제공할 수 있습니다.Pydantic Logfire는 AI 애플리케이션에 대한 관찰 가능성을 제공하며 에피소드를 후원합니다. 에이전트, LLM, API 및 데이터베이스 전반에 걸쳐 인프라 수준까지 통합된 추적을 제공합니다. Logfire는 OpenTelemetry를 활용하며 Postgres 호환 SQL로 모든 데이터를 쿼리할 수 있습니다.스폰서는 AI 애플리케이션도 근본적으로 엔지니어링 노력임을 강조합니다. 개발자가 애플리케이션에 Logfire를 통합할 수 있도록 무료 티어와 쉬운 온보딩 프로세스를 제공합니다.다른 소식으로는 uv가 운영의 보안 강화를 위해 양자 내성 키 교환을 선호하도록 전환했습니다. 이 업데이트는 미래 보장 암호화 방법을 통합하는 추세를 반영합니다.기타 "추가" 항목에는 MCP 서버 업그레이드, postgres를 통한 agentsview 동기화, Talk Python 과정에 대한 새로운 제안, "Lean TDD" 오디오북 출시가 포함됩니다. 에피소드는 개에 대한 짧은 농담으로 마무리됩니다.
"칼 뉴포트는 코딩에서 AI가 주도하는 속도가 좋은 엔지니어링을 정의하는 비판적 사고 능력을 약화시킬 수 있다고 경고한다. 개발자들은 코드를 능동적으로 이해하는 대신 수동적인 인식을 하게 되어, 근본적인 이해에서 멀어질 위험이 있다. 일부는 수동 코딩으로 완전히 돌아갈 것을 주장하지만, 저자는 균형 잡힌 접근 방식을 모색한다. 이 중간 지점은 학습과 기술 개발에 필수적인 마찰을 의도적으로 통합하는 것을 포함한다.기술 퇴화는 AI 자체를 사용하는 것에서 오는 것이 아니라, 내부 모델링 프로세스를 위임하는 것에서 발생한다. 저자는 기술 퇴화와 AI가 미묘하게 잘못된 코드를 생성할 가능성을 구별한다. 소유권과 이해를 유지하기 위해 개발자는 복잡한 코드 경로를 재도출하고 모든 변경 사항을 설명할 수 있는지 확인해야 한다. AI 작업을 잘 정의된 문제로 좁히면 엔지니어가 계속 참여하고 코드 검토가 압도적으로 많아지는 것을 방지할 수 있다.코리 셰이퍼의 상세한 프롬프트와 철저한 코드 검토와 같은 방법은 이러한 마찰을 보존하는 실용적인 방법을 제공한다. 그러나 인간의 주의력은 유한하므로 나머지 작업을 자동화해야 한다. 여기서 "설계에 의한 정확성(correctness by design)"이 중요해지며, 강력한 타이핑 및 컴파일 시간 어설션과 같은 엄격한 시스템 수준 검사를 사용한다.Rust는 유효하지 않은 상태를 표현할 수 없게 만들어 AI 준수를 강제함으로써 이를 예시한다. Python에서는 타입 체커와 유효성 검사 모델이 유사한 목적을 수행한다. 궁극적으로 개발에서 AI를 책임감 있게 사용하려면 판단력을 날카롭게 하기 위해 중요한 결정에 대한 통제권을 유지하고, AI의 책임성을 보장하기 위해 엄격한 규칙을 구현하는 것이 모두 필요하다. 소프트웨어 엔지니어링은 판단과 경험의 과정으로 남아 있으며, AI는 지루한 측면을 자동화한다. 핵심 요점은 가장 중요한 결정을 AI에 위임하는 것을 식별하고 거부하여 진정한 소유권과 견고한 코드를 보장하는 것이다."
저자는 파이썬 패키징에서 재현 가능한 빌드를 위한 정의된 방법론의 부재를 강조합니다. 재현 가능한 빌드는 공급망 보안에 매우 중요하며, 제3자가 배포 콘텐츠가 소스 코드와 일치하는지 확인할 수 있도록 합니다. 이 과정은 빌드 중 변조를 감지하고 손상된 도구의 사용을 식별할 수 있습니다. 순수 파이썬 휠조차도 빌드 백엔드가 손상되면 취약합니다.재현 가능한 빌드를 달성하기 위해서는 소스 코드 위치와 빌드 프로세스에 사용된 소프트웨어라는 두 가지 핵심 정보가 필요합니다. 현재 소스 코드 위치는 sdists나 휠에 명시적으로 기록되지 않지만, 설치 프로그램이 때때로 이를 기록합니다. 배포 메타데이터에 소스 위치 정보를 포함하는 메커니즘이 제안됩니다.빌드 소프트웨어를 기록하기 위해 휠은 소프트웨어 자재 명세서(SBOM)를 활용할 수 있지만, sdists는 유사한 구조화된 형식이 없어 새로운 sdist 버전이 필요할 수 있습니다. 저자는 빌드 백엔드가 실행 환경을 기록할 수 있으며, pip 유지보수자가 배포 생산자에게 부담을 주지 않고 이 정보를 기록하는 데 도움을 줄 수 있다고 제안합니다.재현 가능성을 가시화하고 이점을 제공하기 위해, 신뢰할 수 있는 검증자가 독립적으로 배포를 재현하고 PyPI에 성공을 보고하는 아이디어가 제안됩니다. 이를 통해 사용자는 검증된 배포를 식별하고 더 안전한 공급망의 이점을 누릴 수 있습니다. 이 기능은 사용자를 낙담시키지 않도록 의무 요구 사항이 아닌 선택적 혜택으로 제시되어야 합니다.
CdXz5zHNQW_mXxF48doZc.png
파이썬의 sys 모듈은 여러 잡다한 항목들을 담고 있는 "잡동사니 서랍"으로 묘사됩니다. 이 글은 오늘날 처음부터 설계된다면 sys 모듈이 어떻게 보일지 탐구합니다. 현재 sys는 백 개 이상의 속성을 가지고 있으며, 그중 상당수가 함수여서 네임스페이스가 혼잡합니다. 이를 해결하기 위해 저자는 sys를 아홉 개의 하위 모듈로 재구성할 것을 제안합니다.제안된 하위 모듈에는 명령줄 인수를 위한 sys.cli, 모듈 관련 함수를 위한 sys.imports, 표준 입출력을 위한 sys.io, 대화형 프롬프트 설정을 위한 sys.repl, 시스템 및 설치 세부 정보를 위한 sys.interpreter, 메모리 관리 도구를 위한 sys.memory, 예외 처리를 위한 sys.exceptions, 프로파일링 및 인트로스펙션을 위한 sys.profile, 인터프리터 동작을 위한 sys.runtime이 포함됩니다. 이러한 제안된 하위 모듈 내의 일부 속성은 기존 표준 라이브러리 모듈과 유사점을 가지고 있어 추가적인 재구성을 시사합니다.이 글은 이러한 재구성을 실제로 구현하는 데 따르는 상당한 어려움을 인정합니다. 주로, 전환 기간과 현재 sys의 평면적인 네임스페이스에 의존하는 기존 코드의 하위 호환성 유지가 주요 장애물입니다. 모듈 수준의 속성 처리를 포함하는 기술적 해결책이 논의되며, 호환성을 위해 이전의 평면적인 네임스페이스를 어떻게 보존할 수 있는지 보여줍니다. 그러나 저자는 방대한 양의 기존 코드와 파이썬 커뮤니티가 꼭 필요한 경우가 아니면 이러한 근본적인 변경을 꺼리는 일반적인 성향 때문에 이러한 재구성이 결코 일어나지 않을 것이라고 회의적입니다. 개발자들에게 주요 시사점은 하위 모듈이 큰 "utils" 모듈에 유용한 구성 도구가 될 수 있다는 것입니다.
CdXz5zHNQW_bGZrtpxsuT.png
AI 에이전트는 종종 Python 프로젝트에서 종속성을 잘못 설치하거나 가상 환경을 무시하는 등 어려움을 겪습니다. 이는 설정 오류와 개발자 시간 낭비로 이어집니다. PyCharm의 새로운 Agent Environment Coordinator 기능은 Python 개발에서 AI 에이전트의 성능을 획기적으로 향상시킵니다. 이 기능을 통해 에이전트는 프로젝트별 Python 환경에 액세스하고 활용할 수 있습니다.테스트에서 이 기능은 6가지 AI 모델과 28가지 Python 작업 전반에 걸쳐 평균 작업 성공률을 68%에서 98%로 높였습니다. 중요한 점은 이러한 에이전트가 더 이상 시스템 Python 환경을 오염시키지 않는다는 것입니다. 이전에는 AI 모델이 프로젝트별 인터프리터를 인식하지 못해 전역 설치 및 스크립트 오류가 발생했습니다. Agent Environment Coordinator는 에이전트가 올바른 Python 인터프리터와 해당 관리 도구를 PyCharm에 쿼리할 수 있도록 합니다.환경이 존재하지 않으면 PyCharm의 기존 메커니즘을 사용하여 구성할 수 있습니다. 이 기능은 제어권을 가져가지 않고 컨텍스트를 제공하여 에이전트가 자체적으로 명령을 구성할 수 있도록 합니다. 이는 에이전트가 기존 프로젝트 설정으로 즉시 작동함을 의미하며, 수동 코칭이나 정리의 필요성을 제거합니다. 이 기능은 JetBrains AI 구독을 통해 사용할 수 있습니다. 방법론에는 28가지 일상적인 Python 환경 작업이 포함되었으며, 성공률과 시스템 청결도가 주요 지표였습니다. 결과는 AI 모델이 능력이 부족한 것이 아니라 단순히 필요한 컨텍스트가 부족했음을 명확하게 보여줍니다.
기존 AI 에이전트는 Jupyter 노트북을 다루는 데 어려움을 겪으며, 종종 파일을 손상시키고 완료 시 모델 상태를 잃어버립니다. PyCharm에 통합된 새로운 Jupyter 스킬은 AI 에이전트가 라이브 Jupyter 커널 내에서 작동하도록 함으로써 이 문제를 해결합니다. 이 혁신은 셀 간의 상태 지속성을 보장하여 노트북 손상을 방지합니다. 또한 에이전트가 지속적으로 폴링하는 대신 실행을 기다리도록 하여 긴 작업을 최적화합니다. 이 라이브 커널 접근 방식은 12가지 머신러닝 작업에서 Claude Opus 5에 대해 약 12% 더 저렴한 것으로 입증되었습니다. 비용 절감은 개선된 캐시 워밍 메커니즘에서 비롯되며, 캐시 읽기 비율이 높아집니다. 이전에는 AI 도구가 노트북을 일반 텍스트로 취급하여 서브프로세스를 사용할 때 손상과 중요한 런타임 정보 손실을 초래했습니다. 새로운 Jupyter 스킬은 PyCharm의 내부 노트북 지능을 활용하여 에이전트에게 직접적인 커널 제어를 제공합니다. 이를 통해 에이전트는 변수와 훈련된 모델을 유지하면서 Python 코드를 직접 작성하고 실행할 수 있습니다. 이 스킬은 또한 더 효율적인 대기 메커니즘을 구현하고 새로운 출력만 읽어 토큰 낭비를 줄입니다. 비용 절감은 특히 상태 저장 작업에서 분명하지만, 이 스킬은 다른 모델에 대한 워크플로우 개선도 제공합니다. 사용자에게는 작업을 저장하도록 에이전트에게 명시적으로 지시해야 함을 상기시킵니다. 이 스킬은 근본적인 ML 난이도가 아닌 도구 비효율성을 해결하므로 복잡한 ML 작업에는 여전히 인간의 개입이 필요할 수 있습니다. 이 기능은 JetBrains AI 구독으로 사용할 수 있습니다.
PyQt에서 QTabWidget을 다른 레이아웃과 함께 배치하는 것은 특별한 해결책 없이도 실제로 가능합니다. QTabWidget이 레이아웃을 지배하는 것처럼 보이는 일반적인 문제는 탭 페이지에 내용이나 자체 내부 레이아웃이 없기 때문에 발생합니다. 탭 페이지가 비어 있으면 QTabWidget이 과도한 공간을 요청하여 다른 위젯이 축소될 수 있습니다. 이를 해결하려면 각 탭 페이지에 레이아웃과 일부 내용이 포함되어 있는지 확인하십시오. 또한 QTabWidget에 적절한 크기 정책 또는 늘리기 계수(stretch factor)를 설정하면 이웃 위젯과 공간을 효과적으로 공유하는 데 도움이 됩니다. 최소한의 예제는 QTabWidget을 다른 스택형 위젯과 QHBoxLayout에 결합하는 것을 보여줍니다. 늘리기 계수는 메인 레이아웃 내의 레이아웃과 개별 위젯에 적용하여 사용 가능한 공간의 분배를 제어할 수 있습니다. 예를 들어, QTabWidget에 더 높은 늘리기 계수를 할당하면 더 많은 상대 공간을 차지하게 됩니다. 완전한 예제는 다양한 레이아웃 유형과 QTabWidget을 포함한 여러 섹션을 통합하는 것을 보여주며, 이 모든 것이 조화롭게 공존합니다. 이 접근 방식은 모든 구성 요소가 표시되고 창의 치수를 적절하게 공유하도록 보장합니다. 궁극적으로 핵심은 QTabWidget의 페이지 내에 구조와 내용을 제공하는 것입니다.
Real Python에서 클래스와 객체 지향 설계에 초점을 맞춘 신간 "Modern Object-Oriented Python"을 출간했습니다. bisect 모듈은 Python에서 이진 탐색을 구현하는 데 중점을 두었으며, 해당 함수의 예시가 제공됩니다. PropelAuth는 B2B 애플리케이션에 AI 에이전트를 안전하게 통합하기 위한 솔루션을 후원하고 있습니다. Django와 비동기 프로그래밍에 대한 논의는 상당한 업데이트와 변경 사항을 보여줍니다. 동결 구문 및 확장 가능한 JSON 직렬화를 위한 초안, 비동기 생성기에서 yield from 및 HTML Simple Repository API 동결을 위한 승인된 PEP를 포함한 여러 Python Enhancement Proposal(PEP)이 자세히 설명되어 있습니다. Python 버전 3.14.7 및 3.13.15, 그리고 Django 6.1이 출시되었습니다. 2026년 Python Typing Survey가 참여를 위해 개설되었으며, Python의 타입 시스템의 미래를 안내하는 것을 목표로 합니다. 기사에서는 모듈식 구성을 위한 Hydra 사용, 스레드 프리 빌드에서 asyncio.all_tasks()가 작업을 조용히 삭제할 가능성, 고급 Celery 레시피를 다룹니다. 다른 주제로는 DSPy를 사용한 프로그래밍 방식 LLM 프롬프트 개발, 더 빠른 테스트를 위한 Django의 setUpTestData, 순수 Python에서의 SIMD에 대한 생각이 있습니다. 기능이 추가된 Python 버전을 식별하는 유용한 도구가 소개되었습니다. 추가 기사에서는 Pointblank를 사용한 데이터 유효성 검사 및 Python으로 이메일 보내기를 설명합니다. xy, autowt, vscode-marimo, commerce와 같은 프로젝트가 소개되었습니다. 2026년 8월부터 예정된 Python 및 Django 이벤트 목록이 제공됩니다.
CdXz5zHNQW_14ZOYttUhz.png
저자는 마이크로소프트의 지원을 받지만 독립적인 동기로 최초의 Python Packaging Council(PPC)에 출마하고 있습니다. 저자는 핵심 개발자에 비해 더 넓은 PSF 회원들에게 자신을 소개하는 것이 어렵다는 점을 인정합니다. 저자는 23년 이상 핵심 개발자로 활동하고 수많은 패키징 PEP에 기여하는 등 Python 패키징 분야에서 쌓아온 풍부한 경험을 강조합니다. 또한 Python Steering Council에서 활동했으며 'packaging' 프로젝트를 공동 관리했습니다.후보자로서 저자는 스티어링 위원회 경험을 활용하여 새로운 PPC를 효과적으로 설립하는 데 도움을 주는 것을 목표로 합니다. 핵심 목표는 패키지 생산자와 소비자 모두의 개발자 경험을 개선하는 것입니다. 여기에는 사양을 명확히 하고 효율성을 위해 현재 사양에서 약간 벗어나는 uv와 같은 도구의 성공적인 관행을 채택하는 것이 포함됩니다.또한 저자는 Python 공급망의 보안을 강화하는 데 전념하고 있습니다. 저자는 패키지 무결성에 대한 독립적인 검증을 허용하기 위해 재현 가능한 빌드를 더 쉽게 만들 것을 제안합니다. 저자는 또한 취약점을 식별하고 완화하기 위해 패키징 프로세스 전반에 걸쳐 Software Bills of Materials(SBOM)의 사용을 확대하는 데 가치가 있다고 생각합니다. 저자의 전반적인 비전은 개발자 경험에 부정적인 영향을 주지 않으면서 패키징 보안을 개선하는 것입니다.
텍스트를 줄로 분할하는 겉보기에는 간단한 작업이 역사적이고 진화하는 표준으로 인해 놀랍도록 복잡합니다. 초기 컴퓨팅은 LINE FEED(LF) 및 CARRIAGE RETURN(CR)과 같은 줄 바꿈 제어 문자를 포함하는 ASCII에 의존했습니다. 다른 운영 체제는 이러한 문자의 다양한 조합을 채택하여 일반 텍스트의 이식성 문제를 야기했습니다. 예를 들어, Windows는 CR LF를 사용하고, Unix는 LF를 사용하며, 클래식 Mac OS는 CR을 사용합니다. Python은 파일을 열 때 세 가지 일반적인 줄 바꿈 형식을 모두 인식하는 "유니버설 뉴라인" 모드를 도입하여 이를 해결했습니다. 전통적인 CR 및 LF 외에도 ASCII는 줄 바꿈을 유발하는 FORM FEED(FF) 및 VERTICAL TAB(VT)도 정의했습니다. Unicode의 등장은 줄 바꿈 표시기로서 일곱 개의 새로운 코드 포인트와 CR LF 시퀀스를 도입했습니다. 여기에는 LINE FEED, LINE TABULATION, FORM FEED, CARRIAGE RETURN, NEXT LINE, LINE SEPARATOR 및 PARAGRAPH SEPARATOR가 포함됩니다. 또한 Unicode의 양방향 알고리즘은 양방향 클래스가 'B'인 문자를 단락 구분 기호로 간주하며, 이는 줄 바꿈 역할도 합니다. 여기에는 ASCII 이름 FILE SEPARATOR, GROUP SEPARATOR 및 RECORD SEPARATOR로도 알려진 INFORMATION SEPARATOR FOUR, THREE 및 TWO가 포함됩니다. 총 10개의 개별 코드 포인트와 1개의 다중 코드 포인트 시퀀스가 줄 바꿈으로 Python의 splitlines() 메서드에 의해 인식됩니다. 이 포괄적인 세트는 텍스트 줄 구분을 처리하기 위한 역사적 관례와 현대 Unicode 표준을 수용합니다.
다크 매터 엔터프라이즈 소프트웨어라는 개념은 기업 내에서 구축되었지만 잘 이해되지 않고 종종 방치되는 내부 도구를 지칭합니다. 이러한 도구는 일반적으로 이미 회사를 떠난 개인에 의해 구축되었으며, 이를 수정하거나 업데이트하는 것에 대한 전반적인 꺼림칙함이 있습니다. 결과적으로, 많은 유사한 도구가 그림자 속에 존재하는 채로 시간이 멈춘 듯 고정될 수 있습니다. 마이클 부스는 대기업 내 소규모 팀이 기능적 격차를 메우기 위해 자체 도구를 구축하는 하이퍼 팀 소프트웨어라는 아이디어에 대해 글을 썼습니다. 이러한 접근 방식은 유익할 수 있지만, 제대로 관리되지 않으면 위험을 수반하기도 합니다. 하이퍼 팀 소프트웨어라는 아이디어는 개인적인 사용을 위해 맞춤 제작된 도구를 지칭하는 하이퍼 개인 소프트웨어라는 개념의 확장입니다. 마이클 부스의 기사는 혼란을 방지하기 위한 가드레일의 필요성을 포함하여 하이퍼 팀 소프트웨어의 잠재적 이점과 함정을 탐구합니다. 하이퍼 팀 소프트웨어에 대한 논의는 오래되거나 제대로 유지 관리되지 않는 내부 도구로 인해 기업이 상당한 가치를 잃는 맥락에서 관련이 있습니다. 이 주제는 또한 AI 지원 도구라는 아이디어와 대기업 내에서 혁신을 주도할 수 있는 소규모 팀의 잠재력과도 연결됩니다. 하이퍼 팀 소프트웨어에 대한 대화는 팀이 자체 도구를 구축하도록 허용하는 것과 문제 발생을 방지하기 위해 감독 및 통제 수준을 유지하는 것 사이의 균형을 찾는 것의 중요성을 강조합니다.
저자는 호출자별로 함수의 코드 커버리지를 측정하고자 합니다. 이는 BASIC 인터프리터인 Acidica에서 오류 검사 코드를 리팩토링하는 데서 비롯되었습니다. 초기에는 각 내장 함수가 자체 인자 유효성 검사를 가지고 있어 오류 조건에 대한 특정 커버리지가 가능했습니다. 리팩토링 후, 유효성 검사가 공유 헬퍼 함수로 이동하면서 이러한 상세한 커버리지가 손실되었습니다.제안된 해결책은 coverage.py의 동적 컨텍스트를 활용하는 데코레이터를 포함합니다. 이 데코레이터는 장식된 함수를 실행하기 전에 호출 사이트(파일 및 줄 번호)의 이름을 딴 새로운 커버리지 컨텍스트를 생성합니다. 함수 완료 시 원래 컨텍스트가 복원됩니다.coverage.Coverage.current()cov.switch_context()를 사용하는 개념 증명 데코레이터가 이 기능을 시연합니다. 이를 위해서는 중첩 컨텍스트를 지원하기 위해 coverage.py의 사소한, 아직 출시되지 않은 변경이 필요합니다. 저자는 HTML 커버리지 보고서가 이제 expects 함수의 각 호출자에 대해 별도의 컨텍스트를 보여주어 누가 어떤 분기를 실행했는지 드러낸다는 것을 발견했습니다.향후 개선 사항에는 특정 호출자에 대한 누락된 커버리지를 식별하기 위해 이러한 컨텍스트를 후처리하고, 호출자와 실행 세부 정보를 동시에 추적하기 위해 계층적 또는 다중 컨텍스트를 활성화하는 것이 포함됩니다. 저자는 또한 데코레이터를 사용하여 소스 코드를 수정하는 대신 커버리지 구성을 통해 이 기능을 통합하는 것을 목표로 합니다. 잠재적인 응용 프로그램에는 컨텍스트 식별자로 func_name과 같은 함수 인자를 사용하는 것이 포함됩니다.
CdXz5zHNQW_IFrCzZRuFh.png
저자는 Pandas 실력 향상을 위해서는 깔끔하게 정리된 테이블뿐만 아니라 실제 데이터를 가지고 연습해야 한다고 강조합니다. 저자는 지난 3.5년간 실제 최신 공개 데이터를 기반으로 한 주간 Pandas 연습 문제인 Bamboo Weekly를 작성해 왔습니다. 현재 2년이 지난 이슈들은 500개 이상의 연습 문제와 완전한 풀이와 함께 무료로 제공됩니다. 저자는 실제 데이터가 잘못된 열 이름이나 일관성 없는 날짜 형식과 같이 지저분한 데이터를 처리하는 방법을 가르쳐준다고 강조합니다. Bamboo Weekly의 연습 문제는 실제 문제를 모방하도록 설계되어 있으며, 해결하기 위해 여러 단계를 거쳐야 합니다. 저자는 또한 16가지 일반적인 Pandas 메서드에 대한 메서드 가이드를 제공하며, 메서드가 하는 일, 예시, 일반적인 실수 등을 다룹니다. 이 가이드들은 Pandas 3에 대해 검증되었으며 LernerPython 연습 시스템의 해당 연습 문제에 대한 링크를 포함합니다. 저자는 관심 있는 메서드 가이드나 연습 문제로 시작하여 풀이를 읽기 전에 해결하려고 시도해 볼 것을 제안합니다. Bamboo Weekly의 목표는 데이터 분석 근육 기억력을 향상시켜 업무에서 문제를 해결하는 데 더 자신감을 갖도록 하는 것입니다. 실제 데이터를 가지고 연습하고 일반적인 실수로부터 배움으로써 Pandas 사용 능력을 향상시키고 전반적인 데이터 분석 기술을 개선할 수 있습니다.
한 회사가 전통적인 Postgres 관리 도구와 Langflow와 같은 AI 도구를 통합한 Postgres AI Hybrid Manager용 AI 테스트 프레임워크를 개발 중입니다. 이 챗봇은 제품 기능, 문서 지원, AI 워크플로우를 하나의 대화형 인터페이스로 통합하는 것을 목표로 합니다. 이러한 LLM 지원 에이전트를 테스트하는 것은 응답이 비결정적이며, 유창하더라도 미묘하게 틀릴 수 있기 때문에 도전적입니다. 프레임워크는 최종 답변뿐만 아니라 전체 채팅 경로를 테스트하는 데 초점을 맞추기 위해 진화했습니다."골든"(완벽한 원하는 출력)과 "루브릭"(좋은 답변을 위한 질적 체크리스트) 등 핵심 개념이 소개됩니다. AI 테스트에서는 LLM을 심사위원으로 사용하여 골든 또는 루브릭에 대한 점수를 부여하며, 복잡한 응답을 합격/불합격 결과로 전환합니다. 작업 완료율(TCR)은 여러 평가 패스를 집계하는 데 사용됩니다. 테스트 전략은 간단한 라우팅 평가에서 시작되었으며, 챗봇이 올바른 전문 에이전트나 기술자에게 프롬프트를 전달하는지 확인하는 것이었다.시스템이 도구별 에이전트에서 기술이 통합된 조정 에이전트로 진화함에 따라, 라우팅 평가는 적합한 기술 선택과 가시성을 확인하는 방향으로 조정되었습니다. 이후 챗봇의 전체 응답이 사용자의 과제를 성공적으로 완료했는지 평가하기 위해 TCR 평가가 구현되었으며, 특정 루브릭과 함께 LLM을 심사하는 방식이 적용되었습니다. 이로 인해 두 가지 실행 모드가 생겼습니다: 프롬프트 및 루브릭 개발을 위한 직접 모드와 전체 프로덕션 경로를 테스트하는 프록시 모드입니다.또한 이 프레임워크는 테스트 단위가 단일 턴이 아니라 전체 대화가 되는 다중 단계 대화도 처리해야 했습니다. 이를 위해 프록시 모드에서 여러 API 호출 간 대화 상태를 유지하거나 직접 모드에서 시뮬레이션해야 했습니다. 점수 산정에는 이제 단계별 체크와 전체 대화 점수가 포함됩니다. 기본 테스트 라이브러리는 deepeval로, 회사는 이를 기반으로 파이프라인, 플러그인 시스템, CI 통합, Langfuse 푸시를 구축했습니다. 라우팅은 deepeval에서 맞춤형 'BaseMetric'으로 구현되어 특정 비즈니스 규칙을 LLM 평가 프로세스에 통합할 수 있음을 보여줍니다.
CdXz5zHNQW_2wtMsPJlJt.png