Planet Python 日本語 ノート

Planet Python 日本語

Planet Pythonは、Python関連の内容を様々なソースから集めたプラネットサイトです。ブログ、ニュースサイト、他のオンライン出版物が含まれます。 このサイトは、Pythonプログラミングの世界で最新の開発状況を追跡するためのワンストップデスティネーションを提供します。サイトの内容には、チュートリアル、ニュース、プロジェクトの発表、Python関連の様々なトピックに関する議論が含まれます。 ユーザーは、Pythonコミュニティ、最新リリース、会議、Pythonプログラミング言語の使用に関するベストプラクティスに関する情報を入手するためにサイトを訪れることができます。このサイトの目的は、Python関連の内容を宣伝し、普及させることで、Pythonコミュニティの成長と発展に貢献することです。

ノートのスレッド

著者は、グローバルなフィードバックに基づきLernerPythonの改善に注力しており、いくつかの重要なアップデートが行われました。開発者にとってAIの重要性が増していることに対応するため、LernerPythonのメンバーシップに月例AIセミナーが追加されます。8月24日に予定されている最初のセミナーでは、Claude Codeをスーパーシェルとして使用することに焦点が当てられます。さらに、著者の膨大な教材でトレーニングされたAI搭載のソクラテス式チューターがLernerPython.comで利用可能になりました。このチューターは、ユーザーが母国語で質問できるようサポートします。Bamboo Weeklyの過去の号は2年後に無料でアクセスできるようになり、数百のデータ分析演習が提供されます。著者はまた、Bamboo Weeklyで使用されているPandasメソッドの新しいドキュメントを作成し、実践的な例とよくある間違いを特集しています。これらの新しいPandasメソッドの説明は、非購読者でも利用できます。今後のオフィスアワーの包括的なカレンダーと過去の録画セッションのライブラリが、LernerPython.comのイベントページでアクセスできるようになりました。これらの変更は、学習を強化し、PythonおよびAI開発のためのよりアクセスしやすいリソースを提供することを目的としています。
著者は休止期間を経て、ブログ記事の執筆を再開しています。最近、FOSS4G UK 2026での講演が採択されたことをきっかけに、FOSS4G UK 2025で自身が主導したワークショップについて執筆しました。ワークショップでは、pg_tileservツールを使用してPostGISデータベースからライブベクタータイルを生成することに焦点を当てました。参加者は、テーブルやPostGIS関数から直接タイルを配信する方法を学び、実践的な演習も提供されました。ワークショップは、複雑な地理空間ワークフローにおけるオンザフライのベクタータイル生成の力を実証することを目的としていました。また、著者はElectromagnetic Fieldフェスティバルで「Lights, Spectrometer, Action!」というタイトルの講演も行いました。この講演では、分光器を用いたライブデモンストレーションを交えながら、分光法の科学を探求しました。様々な光源からの光と異なる物質との相互作用を調べました。講演では、分光法の衛星画像への応用や、化学における潜在的な用途にも触れました。今後、著者はFOSS4G UK 2026で、Environment AgencyのDEMデータへのアクセスを容易にする方法について講演する予定です。このデータは、STACやCOGのようなクラウドネイティブな形式に変換されており、アクセスと分析が容易になっています。この作業により、DEMモザイクやカスタムWebマップの視覚化を効率的に作成できます。著者はまた、分光器制御用のカスタムソフトウェアも開発しています。
CdXz5zHNQW_3HN87m7Gll.png
LLMの台頭はプログラミングプロセスを大幅に効率化し、開発者にとって言語選択の重要性を低下させました。コードを異なる言語で書き直したり、慣れない言語でコードを生成したりする能力は、人間にとっての摩擦を軽減します。この変化により、言語選択はパフォーマンスのようなマーケティングや認識されているメリットによってより推進されるようになります。例えば、Rustは、より高速なソフトウェアへの欲求の高まりや、LLMによる効率的なコード最適化能力により、採用が増加しています。パフォーマンスに重点を置くことで知られるMitchell Hashimoto氏のような専門家も、エージェントによって書かれたコードを受け入れています。autoresearchのようなツールは、開発者が広範な事前知識を必要とせずに最適化を達成することを可能にします。Rust以外にも、Zigのような他の「ハード言語」も、スピードとフットプリントの小ささを目指すプロジェクトで注目を集めています。CloudflareのArtifactsサービスとVercelのfxエージェントは、どちらもZigを利用しており、このトレンドを例示しており、多くの場合LLMの支援を受けています。さらに、開発者は現在、DWARFファイル、eBPF、カスタムネットワークドライバー、さらには古いコンピューティングハードウェアのような、従来は困難であったテクノロジーに取り組んでいます。これらの領域の多くは、以前はアクセス不可能であったり、意図的にアクセスが制限されていました。この変化はいくらかの「緩み」をもたらすかもしれませんが、スピードと効率性を重視するより多くの開発者を取り込み、高性能ソフトウェアの新しい時代につながる可能性があります。
Djangoのsigningモジュールは、ユーザーのログインやセッションなしで安全な購読解除リンクを可能にします。URLに直接ユーザーIDを使用する安全でないアプローチは、大量購読解除の脆弱性があります。データベースにランダムなトークンを保存するのは一般的な修正ですが、より複雑です。Djangoのdjango.core.signingモジュールは、SECRET_KEYで値(ユーザーの主キーなど)に署名することにより、データベースストレージを必要とせずに改ざん防止トークンを提供します。「ソルト」は、異なる機能間のトークン衝突を防ぐために重要であり、ある目的(例:お知らせ)のトークンを別の目的(例:フォーラム通知)に使用できないようにします。署名されているとはいえ、トークンは秘密ではなく、その中のデータは読み取り可能ですが、署名を無効にせずに変更することはできません。したがって、隠すべき機密情報を署名しないでください。重要なのは、メールスキャナーやプリフェッチャーが意図せずユーザーを購読解除してしまうのを防ぐために、購読解除アクションはGETリクエストではなくPOSTリクエストで行うべきです。GETでの確認ページ、それに続いてアクションを完了するためのPOSTが推奨されるフローです。購読解除トークンは、古いリンクを2回クリックしても同じ安全な結果が得られるため、有効期限が不要な場合が多いです。しかし、マジックログインリンクのような機密性の高いアクションでは、signing.loadsmax_age引数がデータベースストレージなしで有効期限を提供します。メール検証のような一度限りのトークンシナリオでは、署名だけでは使用状況を追跡できないため、追加の状態管理(使用済みトークンのデータベースレコード)が必要です。
CdXz5zHNQW_kaNMCAHtWT.webp
DjangoCon US 参加者は、Django Software Foundation に関する 45 分間のオープンスペースセッションにご招待します。このイベントは 8 月 26 日水曜日、午後 1 時から午後 1 時 45 分まで、Wolf Point Ballroom で開催されます。DSF 理事およびその他の DSF 代表者が、自由な議論と質問への回答のために出席します。主なトピックには、資金調達の取り組みと 50 万ドルの目標、特に Django Fellows への資金提供が含まれます。DSF 初の Executive Director の継続的な募集についても議論され、応募締め切りは 2026 年 9 月 14 日です。個人会員、会員になる方法、および投票権などの会員特典に関する情報が共有されます。セッションでは、ワーキンググループやチームについても取り上げ、参加に会員資格は必要ないことを明確にします。技術ガバナンスに関する DEP 19、および Django のリリーススケジュールに関する DEP 20 の最新情報が提供されます。このオープンスペースは、すべての参加者が、現在の DSF 会員資格に関係なく、財団の運営と意思決定について質問できるようにすることを目的としています。財団自体に関する質問は歓迎しますが、特定のコードの問題に関する質問はご遠慮ください。参加できない場合は、"Contact the DSF" ページまたは Django Forum を通じて質問を送信できます。
最近の調査によると、AIはほとんどの開発者のワークフローに不可欠であり、90%が週に1回または毎日使用しています。AIはコードを迅速に記述できますが、開発者はその出力を理解し、評価し、承認する責任を負います。これはIDEの重要な役割を強調しており、PyCharmは開発者の制御を強化するツールとして注目されています。PyCharmを使用すると、ユーザーは好みのAIエージェントとモデルを選択でき、主要なオプションのネイティブサポートと、それ以上のための広範なレジストリを提供します。ユーザーはJetBrains AIサブスクリプションを選択するか、OllamaやLM Studioを介したローカルモデルを含む独自のツールを活用できます。IDEは、再利用可能な「スキル」を通じて、特定のプロジェクトの規約とコーディング標準でAIエージェントをトレーニングすることも開発者に可能にします。PyCharmは、最新の機能を含むDjangoの堅牢でバージョン固有のサポートを提供し、AIトレーニングデータが古い場合でも整合性を確保します。さらに、IDEは、ビジュアルdiffや統合されたGit履歴などのコードレビューのための包括的なツールと、バージョン管理に依存せずに変更を追跡するためのローカル履歴機能を提供します。PyCharmのDjango論理構造ビューは、フレームワークの観点からアプリケーションのアーキテクチャを視覚化し、理解を助けます。最後に、そのエンドポイントツールウィンドウとデータエディタ/ビューアは、API検証とデータベースインタラクションを容易にし、開発者がAI生成コードとその影響を自信を持って評価できるようにします。
大規模言語モデル(LLM)は、特にコードレビューの量に関して、オープンソースソフトウェアコミュニティ内に既存の危機を悪化させています。この圧力はオープンソースを超えて広がり、コンピューティング分野全体に影響を与えています。LLMは、たとえそれらを避けようとする人々にとっても、プログラミングの方法を根本的に変えています。ユーザーはLLMを使用して大規模なコードレビューを自動化しており、かなりのコンピューティングコストが発生しています。この自動化は、API価格の変更の可能性についての懸念を引き起こし、実質的に以前よりもアクセスしやすかったものに料金を課すことになります。フリーおよびオープンソースソフトウェアの提唱者である著者は、コンパイラのようなツールを入手することが大きな出費であった過去の時代を反映して、ソフトウェアをレンタルする方向へのシフトを観察しています。現在、多くのソフトウェアツールやLLMへのアクセスには継続的な月額料金が必要であり、開発者は仕事をするためにお金を払わなければならない状況につながっています。この傾向は「エンシフィケーション」と見なされており、企業は盗まれた作品でモデルをトレーニングし、それを開発者に売り戻しています。さらに、LLMはエンジニアリングの仕事への脅威として提示されており、機会が少なく給与が低い、悪化する雇用市場に貢献しています。テクノロジー企業は、自社が管理するモデルの使用を推進することで、エンジニアリング profession を積極的に攻撃していると見なされています。LLMの使用が義務付けられていなくても、LLMによって生成された作業に追いつくためのプレッシャーは非常に大きく、サプライチェーンのセキュリティを危険にさらす可能性があります。著者は、LLMの誇大広告は、労働者と環境に対するより広範な社会的な攻撃の一部であると主張しています。これに対処するには、個々の適応ではなく、集団的な政治的および社会的な行動が必要です。
PyCharm 2026.2 は、Python コードインサイトの強化に焦点を当てた 263 件の修正と改善を導入します。主なアップデートには、型推論の向上、偽陽性の削減、リファクタリングの信頼性向上などが含まれます。このリリースでは SQLAlchemy 2.0 のサポートが改善され、以前は問題となっていた多くのシナリオが解決されました。コードインサイトは、制御フローの狭窄と到達不能コードの処理における修正から恩恵を受けます。型アノテーション内の文字列とイテラブルアンパッキングは、より正確な分析が見られるようになりました。増分代入とコンストラクタの戻り値の型も、より正確に分析されます。Enum メンバーは、その値と名前属性に対して Literal 型を生成するようになりました。パラメータの型はデコレータから推論されるようになり、補完と自動インポートがより賢くなりました。PyCharm は現在、既存のインポートの再利用を優先し、ネストされたクラスの自動インポートをサポートしています。unittest.mock.patch ターゲットの補完が機能するようになり、組み込みメソッドのオーバーライドは完全なアノテーション付きシグネチャを埋め込むようになりました。型インレイヒントは、推論された型引数をインラインで表示し、f-string のフォーマット仕様の検証が拡張されました。Rename リファクタリングはモジュール参照を正しく更新するようになり、Field リファクタリングは Attribute と改称されました。全体として、これらの強化により、PyCharm 内での Python コードの理解がより正確で予測可能になります。
Python Software Foundation (PSF) は、PyPI、Python.org、CPython のような重要なインフラストラクチャを管理し、様々な分野での Python の広範な利用を支援しています。PSF のインフラストラクチャのほとんどは AWS 上で稼働しており、AWS の Open Source Credits Program によってかなりのコストがカバーされています。PyPI は毎日数十億件のリクエストを処理しており、Fastly のエッジキャッシングにより AWS のオリジンサーバーへのアクセスを減らしています。しかし、ユーザーアップロードのようなキャッシュされないインタラクションは、EC2、RDS、S3 のようなサービスによって管理されています。今年、AWS の支出は 69% 著しく増加しており、これは 8 年間の安定したコストからの逸脱です。この増加は、より多くのユーザーからの利用増加、パッケージをインストールする自動化エージェント、そして多数の CI 実行に起因すると考えられています。PSF は、GitHub Actions のような人気のあるツールのアップストリーム修正を提唱するなど、クレジットの効率的な利用を強調しています。現在進行中の主要なプロジェクトは、より良いオートスケーリングのためにフリート全体を Amazon EKS に移行することです。現在、インフラストラクチャ作業は少人数のチームに大きく依存しており、エンジニアリングスタッフの増員が喫緊の課題となっています。PSF は、サービスを強化し、サプライチェーンリスクを軽減するために、PyPI Organization アカウントやサービス契約を通じた資金調達を求めています。
.uiファイルやQt Designerに依存せずにPySide6アプリケーションを作成することは完全に可能です。開発者は、ウィンドウ、ボタン、ラベルを含むすべてのGUI要素をPythonコード内で直接構築できます。このアプローチは、より大きな制御を提供し、すべてのインターフェースロジックを統合したままにします。基本的なPySide6アプリケーションには、表示するためのQApplicationインスタンスとQWidgetが必要です。ウィジェットは作成され、ウィンドウに親子関係を持たせることができますが、レイアウトがない場合、それらは固定位置を占めます。QVBoxLayout、QHBoxLayout、QGridLayoutなどのQtレイアウトは、ウィジェットを自動的に配置するために不可欠です。複雑さを管理するために、QWidgetまたはQMainWindowをサブクラス化することが推奨されます。シグナルとスロットはインタラクティビティを可能にします。たとえば、ボタンの「clicked」シグナルをPython関数に接続できます。QMainWindowは、メニュー、ツールバー、ステータスバーのフレームワークを提供し、コンテンツはセントラルウィジェットに配置されます。ネストされたレイアウトは、addLayout()を使用してあるレイアウトを別のレイアウトに追加することで実現できます。デモンストレーションは、インタラクティブな要素とステータスバーを備えたプログラムによるGUI作成を示す、完全なQMainWindowアプリケーションで締めくくられます。
最近の論文で、クローズドウェイトモデルから推論トレースを抽出する方法が明らかになり、オンラインで議論が巻き起こりました。推論トレースは通常、ユーザーからは隠されていますが、オープンウェイトモデルでは可視的です。これらのトレースは、モデルが最終的な回答の前にスクラッチパッドに出力するように訓練されたテキストにすぎません。特殊トークンがこれらの推論セクションを区切り、パーサーがこのコンテンツを別のストリームに誘導します。クローズドモデルの場合、この中間テキストは編集または要約される可能性が高いです。モデルが行う推論の量は、サンプリングではなく、システムプロンプトによって決定されます。たとえば、「低」または「ショートカットを一切許可しない絶対最大値」に設定される場合があります。モデルは、このスクラッチワークを最終応答チャネルから分離するように訓練されています。モデルを推論チャネル内にいると信じ込ませることで、これらのトレースが漏洩する可能性があります。古いモデルでは、思考が無効になっている場合、思考をヌルデバイスに書き込むことがありました。場合によっては、唯一の特別な動作は、モデルが思考を控える能力です。これは、モデルの通常の思考メカニズムを無効にすることで達成できます。一部の推論APIは、推論を管理するためにトークンを事前に入力する場合がありますが、これはカスタムツールによってバイパスされる可能性があり、特にネイティブ推論が無効になっている場合に顕著です。著者は、このブログ投稿自体の文法チェックに特定のモデルを使用しようとした際に、ユーモラスにもコンテンツフィルターに遭遇しました。
CdXz5zHNQW_KvYYV2hcVr.png
CdXz5zHNQW_XCM4q7iYG0.png
Python 3.12.14、3.11.16、および3.10.21がセキュリティ修正のみのアップデートとしてリリースされました。これらのリリースは、tarfileの強化、パス・トラバーサル回避、およびPythonの標準ライブラリに関連する複数のCVEなど、複数の重大な脆弱性に対処しています。これらのバージョンを使用しているユーザー、特に信頼できないtarballを扱うユーザーは、アップデートを強く推奨します。Codebergによる、主にAIによって生成されたプロジェクトの最近の禁止措置は、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」オーディオブックのリリースが含まれます。エピソードは、犬に関する短いジョークで締めくくられます。
インターネット標準では、非ASCII文字のサポートが不足していることが多く、ドメイン名のマッピングが必要となります。RFC 3491で定義されているNamePrepは、IDNA 2003の一部としてこの目的のために設計されました。この古いIDNA標準は、その後、RFC 5890-5893で指定されているIDNA 2008に置き換えられました。Pythonは両方のバージョンをサポートしており、IDNA 2003はidnaコーデックを介して、IDNA 2008は外部のidnaパッケージを介してアクセスできます。Pythonの標準ライブラリにあるstringprepモジュールは、StringPrepを実装しています。StringPrepの重要なステップは「ケースフォールディング」であり、大文字小文字を区別しない比較のために文字を小文字または大文字にマッピングすることを含みます。このプロセスは、Unicode 3.2.0のルールに基づいたRFC 3454のテーブルB.2およびB.3を使用します。Pythonの実装では、新しいUnicodeバージョンを使用する標準のstr.lower()関数が、必要なUnicode 3.2.0のケースフォールディングルールから逸脱するという脆弱性が特定されました。この不一致により、特定の文字に対して異なるIDNAエンコーディングが発生しました。修正には、Pythonのstr.lower()の動作がStringPrepおよびIDNA計算のためにUnicode 3.2.0と一致することを保証するための特定の例外を作成することが含まれていました。この修正により、IDNA 2003の仕様との一貫性が保証されます。
Cal Newportは、コーディングにおけるAI駆動のスピードが、優れたエンジニアリングを定義する批判的思考スキルを損なう可能性があると警告しています。開発者は、コードを積極的に理解する代わりに、受動的な認識に陥り、基礎的な理解から乖離するリスクを負います。手作業によるコーディングへの完全な回帰を主張する人もいますが、著者はバランスの取れたアプローチを求めています。この中間的なアプローチには、学習とスキル開発に不可欠な摩擦を意図的に組み込むことが含まれます。スキルの低下は、AI自体を使用することからではなく、内部モデリングプロセスを委任することから起こります。著者は、スキルの低下と、AIが微妙に間違ったコードを生成する可能性を区別します。所有権と理解を維持するために、開発者は複雑なコードパスを再導出し、すべての変更を説明できることを確認する必要があります。AIタスクを明確に定義された問題に絞り込むことは、エンジニアの関与を維持し、圧倒的なコードレビューを防ぐのに役立ちます。Corey Schaferの方法論、例えば詳細なプロンプトと徹底的なコードレビューは、この摩擦を維持するための実践的な方法を提供します。しかし、人間の注意は有限であり、残りのタスクの自動化が必要となります。ここで「設計による正しさ」が重要になり、強力な型付けやコンパイル時アサーションのような厳格なシステムレベルのチェックが採用されます。Rustは、無効な状態を表現不可能にすることで、AIのコンプライアンスを強制するという点でこれを例示しています。Pythonでは、型チェッカーや検証モデルが同様の目的を果たします。最終的に、開発におけるAIの責任ある使用は、判断力を磨くために重要な決定の制御を維持することと、AIの説明責任を確保するための厳格なルールの実装の両方を必要とします。ソフトウェアエンジニアリングは、AIが退屈な側面を自動化する、判断と経験のプロセスであり続けます。重要なのは、最も重要な決定をAIに委任しないことを特定し、真の所有権と堅牢なコードを確保することです。
著者は、Pythonパッケージングにおける再現可能なビルドのための明確な方法の欠如を強調しています。再現可能なビルドは、サプライチェーンセキュリティにとって極めて重要であり、第三者が配布物の内容がソースコードと一致することを確認できるようにします。このプロセスは、ビルド中の改ざんを検出し、侵害されたツールの使用を特定することができます。純粋なPythonホイールであっても、ビルドバックエンドが侵害されている場合は脆弱です。再現可能なビルドを実現するには、ソースコードの場所とビルドプロセスで使用されるソフトウェアという2つの重要な情報が必要です。現在、ソースコードの場所はsdistsやホイールに明示的に記録されていませんが、インストーラーが記録する場合もあります。配布メタデータにソースの場所情報を含めるメカニズムが提案されています。ビルドソフトウェアの記録のために、ホイールはSBOM(Software Bill of Materials)を利用できますが、sdistsには同様の構造化された形式がないため、新しいsdistバージョンの必要性が生じます。著者は、ビルドバックエンドが実行環境を記録し、pipメンテナーが配布物の作成者に負担をかけずにこの情報を記録するのを支援できると提案しています。再現性を可視化し、有益にするために、信頼できる検証者が独立して配布物を再現し、PyPIに成功を報告するというアイデアが提案されています。これにより、ユーザーは検証済みの配布物を特定し、より安全なサプライチェーンの恩恵を受けることができます。この機能は、ユーザーを落胆させないように、必須要件ではなく、オプションの特典として提示されるべきです。
著者は、Swiftの型付きスロー(typed throws)において、エラーハンドリングを簡素化する貴重な機能を発見しました。当初、著者は型付きスローが特定のエラータイプに非常に役立つと感じていましたが、複雑なコードブロックが原因でSwiftがエラータイプを「any Error」に広げてしまう問題に遭遇しました。これにより、「catch」ブロックがエラーを正確に型付けできなくなり、コンパイルエラーが発生しました。著者の回避策は「catch let error as MyError」を使用することでしたが、これには到達不能なcatch-allブロックが必要となり、エラーハンドリングが不完全で不満の残るものとなりました。決定的な発見は、「do throws(MyError)」構文でした。これにより、「do」ブロックで期待されるエラータイプを明示的に宣言することで、Swiftコンパイラは正確なエラー型付けを維持します。このエレガントな解決策は、コンパイラが混乱するのを防ぎ、「catch」ブロックが指定されたエラータイプを正しく処理することを保証します。この機能は、Swiftで型付きスローを扱う際のエラーハンドリングの明確さと完全性を向上させます。著者が元の機能拡張提案でこの詳細を見落としていたことは、大きなミスでした。これで、すべてが型付けされたユニコーンと太陽の光です。
Wing Python IDE バージョン 12.0.2 がリリースされ、いくつかの新機能と改善が追加されました。このリリースには、Wing のネイティブ ARM64 Windows バージョン、Windows 上でのリモート開発の改善、パフォーマンスと応答性の向上が含まれています。新バージョンでは、Claude Code のセットアップも効率化され、分析キャッシュデータベースのサイズが約 20% 削減されます。Wing 12 は、Claude Code AI コーディングエージェントを IDE に直接統合し、新しい Claude Code ツールと AI エージェントの作業の計画とレビューのための Tasks ツールを備えています。この IDE は、機能ベースの 2 つの製品ティアで利用可能です。Wing Pro はフル機能の Python IDE、Wing Classic は完全な従来の Python IDE です。Wing 12 には、自動テストファイル検出、ソースコード分析の改善、外部で変更されたファイルの検出速度の向上など、他にも多くの改善が含まれています。製品ラインは簡素化され、商用および非商用の使用の区別は、機能ベースの 2 つの製品ティアに置き換えられました。Wing Personal の既存ユーザーは、Personal 11.x を無期限に使用し続けるか、無料の Wing 101 に切り替えるか、Wing Classic ライセンスを購入することができます。全体として、Wing 12 は、AI 主導のコーディングツールやパフォーマンスと応答性の向上を含む、開発エクスペリエンスを向上させるためのさまざまな新機能と改善を提供します。
CdXz5zHNQW_mXxF48doZc.png
Pythonのsysモジュールは、多くの雑多なアイテムを保持する「ジャンクの引き出し」として説明されています。この記事では、もしsysモジュールが今日ゼロから設計されたら、どのようなものになるかを考察します。現在、sysには100を超える属性があり、その多くが関数であるため、名前空間が混雑しています。これを解決するために、著者はsysを9つのサブモジュールに再編成することを提案しています。提案されているサブモジュールには、コマンドライン引数のためのsys.cli、モジュール関連の関数のためのsys.imports、標準入出力のためのsys.io、インタラクティブプロンプト設定のためのsys.repl、システムおよびインストールの詳細のためのsys.interpreter、メモリ管理ツールのためのsys.memory、例外処理のためのsys.exceptions、プロファイリングとイントロスペクションのためのsys.profile、およびインタプリタの動作のためのsys.runtimeが含まれます。これらの提案されたサブモジュール内のいくつかの属性は、既存の標準ライブラリモジュールと類似しており、さらなる再編成の可能性を示唆しています。この記事では、このような再編成を実際に実装することの大きな課題を認識しています。主に、移行期間と、現在のsysのフラットな名前空間に依存する既存のコードの後方互換性の維持が大きな障害となります。モジュールレベルの属性処理を含む技術的な解決策が議論されており、互換性のために古いフラットな名前空間をどのように維持できるかを示しています。しかし、著者は、既存のコードの膨大な量と、Pythonコミュニティが、絶対に必要な場合を除いて、このような基本的な変更を行うことに一般的に消極的であるため、この再編成が決して起こらないだろうと疑っています。開発者にとっての主な教訓は、サブモジュールが大規模な「ユーティリティ」モジュールのための有用な整理ツールとなり得るということです。
Django Software Foundation Board は、毎週水曜日の UTC 18:00 に、招待状やアジェンダなしで Django コミュニティの全メンバーが参加できる、週次のオープンオフィスアワーを開催しています。2024年10月から継続されているこれらのセッションは、理事会やその他の主要人物との直接的なコミュニケーション手段を提供します。現在、理事会は特に Django Executive Director の募集について話し合うことに興味を持っています。潜在的な応募者には、その役割や応募プロセスに関する質問をするためにオフィスアワーに参加することを奨励しています。財団はまた、Executive Director の採用を支援するために、2026年の資金調達目標を500,000ドルに引き上げ、月額約16,000ドルの継続的なサポートが必要となります。この目標を達成するために、企業スポンサーシップと寄付を求めています。これらの特定のトピック以外にも、オフィスアワーではワーキンググループの活動、進行中の財団プロジェクト、および一般的なDSFの運営について話し合われます。コミュニティメンバーは、理事会会議の前にフィードバックを提供するためにこの時間を利用することもできます。ただし、オフィスアワーは一般的なDjangoサポートや製品マーケティングを目的としたものではありません。水曜日に参加できない場合は、他のコミュニケーションチャネルが利用可能です。
PyCharm 2026.2 は、AI エージェントがライブカーネルを使用して Jupyter Notebook 内で直接作業できるようになる、大幅な AI 統合を導入しています。変数とモデルのこの永続性は、機械学習ワークフローの信頼性を向上させます。このリリースでは、AI エージェントが正しいプロジェクト環境にパッケージをインストールすることを保証することで、パッケージ管理の問題も解決します。Marimo Notebook は、新しいサードパーティプラグインを介してサポートされるようになり、IDE 内でのリアクティブセルとインタラクティブ UI 要素が可能になります。パフォーマンスとフォーカスを向上させるために、PyCharm は Data Wrangler や Hugging Face のようなあまり使用されないプラグインをバンドル解除します。Python Packages ツールウィンドウは、依存関係の視覚化を改善し、パッケージ管理を高速化するために再設計されました。型チェックメッセージは、不一致の詳細な内訳により、より明確で実用的なものになりました。サポートが終了した Python バージョンの仮想環境の作成は、もはやサポートされません。SQLAlchemy 2.0 の Session.get() 推論は、モデルインスタンスの認識を改善するために強化されました。これらのアップデートは PyCharm 2026.2.1 で利用可能であり、特に AI に焦点を当てたプロジェクトで、より合理化された強力な開発エクスペリエンスを提供することを目的としています。
CdXz5zHNQW_bGZrtpxsuT.png
AIエージェントは、Pythonプロジェクトにおいて依存関係を誤ってインストールしたり、仮想環境を無視したりすることが多く、その結果、セットアップが壊れたり、開発者の時間が無駄になったりします。PyCharmの新しいAgent Environment Coordinatorスキルは、Python開発におけるAIエージェントのパフォーマンスを劇的に向上させます。これにより、エージェントはプロジェクト固有のPython環境にアクセスし、利用できるようになります。テストでは、このスキルにより、6つのAIモデルと28のPythonタスク全体で、平均タスク成功率が68%から98%に向上しました。重要なのは、これらのエージェントがシステムPython環境を汚染しなくなったことです。以前は、AIモデルはプロジェクト固有のインタープリターを認識できず、グローバルインストールやスクリプトの失敗につながっていました。Agent Environment Coordinatorは、エージェントがPyCharmに正しいPythonインタープリターとその管理ツールを問い合わせることを可能にします。環境が存在しない場合は、PyCharmの既存のメカニズムを使用して構成できます。このスキルは、制御を奪うことなくコンテキストを提供し、エージェントがコマンド自体を構築できるようにします。これは、エージェントが既存のプロジェクトセットアップでそのまま動作することを意味し、手動でのコーチングやクリーンアップの必要がなくなります。この機能は、JetBrains AIサブスクリプションで利用できます。この方法論には、28の日常的なPython環境タスクが含まれ、成功とシステムのクリーンさが主要な指標でした。結果は、AIモデルには能力の欠如ではなく、単に必要なコンテキストの欠如があったことを明確に示しています。
従来のAIエージェントはJupyter Notebookの扱いに苦労しており、ファイルが破損したり、完了時にモデルの状態が失われたりすることがよくあります。PyCharmに統合された新しいJupyterスキルは、AIエージェントがライブJupyterカーネル内で動作できるようにすることで、この問題に対処します。このイノベーションにより、セル全体で状態が永続化され、Notebookの破損を防ぎます。また、エージェントが常にポーリングするのではなく実行を待機させることで、長時間ジョブを最適化します。このライブカーネルアプローチは、12の機械学習タスク全体でClaude Opus 5に対して約12%安価であることが証明されました。コスト削減は、キャッシュウォーミングメカニズムの改善に起因し、キャッシュ読み取りの割合が高くなりました。以前は、AIツールはNotebookをプレーンテキストとして扱っていたため、サブプロセスを使用した場合に破損や重要なランタイム情報の損失につながっていました。新しいJupyterスキルは、PyCharmの内部Notebookインテリジェンスを活用して、エージェントに直接カーネル制御を提供します。これにより、エージェントはPythonコードを直接書き込み、実行し、変数やトレーニング済みモデルを維持できます。このスキルは、より効率的な待機メカニズムも実装しており、新しい出力のみを読み取ることで、トークンの無駄を削減します。コスト削減は、特にステートフルなジョブで明らかですが、このスキルは他のモデルに対してもワークフローの改善を提供します。ユーザーは、作業を保存するようにエージェントに明示的に指示することを忘れないでください。複雑なMLタスクは、このスキルが基本的なMLの難しさではなく、ツールの非効率性に対処するため、依然として人間の介入が必要になる場合があります。この機能は、JetBrains AIサブスクリプションで利用できます。
PyQtでQTabWidgetを他のレイアウトと並べて配置することは、特別な回避策なしに可能です。QTabWidgetがレイアウトを支配しているように見える一般的な問題は、そのタブページにコンテンツや独自の内部レイアウトがないことに起因します。タブページが空の場合、QTabWidgetは不均衡なスペースを要求する可能性があり、他のウィジェットが縮小する原因となります。これを解決するには、各タブページにレイアウトと何らかのコンテンツが含まれていることを確認してください。さらに、QTabWidgetに適切なサイズポリシーまたはストレッチファクターを設定すると、他のウィジェットと効果的にスペースを共有するのに役立ちます。最小限の例では、QTabWidgetと他のスタックウィジェットをQHBoxLayoutに組み合わせる方法を示しています。ストレッチファクターは、メインレイアウト内のレイアウトや個々のウィジェットに適用して、利用可能なスペースの分布を制御できます。たとえば、QTabWidgetに高いストレッチファクターを割り当てると、相対的なスペースが増えます。完全な例では、さまざまなレイアウトタイプやQTabWidgetを含む複数のセクションを統合する方法を示しており、すべてが調和して共存しています。このアプローチにより、すべてのコンポーネントが表示され、ウィンドウの寸法が適切に共有されることが保証されます。最終的に、重要なのは、QTabWidgetのページ内に構造とコンテンツを提供することです。
Real Python は、クラスとオブジェクト指向デザインに焦点を当てた新刊「Modern Object-Oriented Python」をリリースしました。bisect モジュールは、Python でバイナリサーチを実装するために取り上げられ、その関数の例が示されています。PropelAuth は、AI エージェントを B2B アプリケーションに安全に統合するためのソリューションをスポンサーしています。Django と非同期プログラミングに関する議論は、重要なアップデートと変更を明らかにしています。フリーズ構文と拡張可能な JSON シリアライゼーションのドラフト、および async ジェネレータでの 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
著者は、独立した動機を持ちながらも、Microsoftの支援を受けて、初のPython Packaging Council(PPC)に立候補しています。コア開発者と比較して、より広範なPSFメンバーに自身を紹介することの難しさを認識しています。著者は、23年以上にわたるコア開発者としての経験や、パッケージングPEPへの数多くの貢献を含む、Pythonパッケージングにおける豊富な経験を強調しています。また、Python Steering Councilのメンバーを務め、「packaging」プロジェクトの共同メンテナーも務めました。候補者として、著者はステアリングカウンシルの経験を活かして、新しいPPCを効果的に確立することを目指しています。主な目標は、パッケージの作成者と消費者の両方にとっての開発者体験を向上させることです。これには、仕様の明確化や、効率のために現在の仕様からわずかに逸脱しているuvのようなツールの成功したプラクティスの採用が含まれる可能性があります。さらに、著者はPythonサプライチェーンのセキュリティ強化に尽力しています。パッケージの整合性を独立して検証できるように、再現可能なビルドを容易にすることを目指しています。著者はまた、脆弱性を特定し軽減するために、パッケージングプロセス全体でSoftware Bill of Materials(SBOM)の使用を拡大することに価値を見出しています。著者の全体的なビジョンは、開発者体験に悪影響を与えることなく、パッケージングセキュリティを向上させることです。
テキストをラインに分割するという一見単純なタスクは、歴史的および進化する標準により、驚くほど複雑です。初期のコンピューティングはASCIIに依存しており、ラインブレークのためにLINE FEED (LF) および CARRIAGE RETURN (CR) のような制御文字を含んでいました。異なるオペレーティングシステムはこれらの様々な組み合わせを採用し、プレーンテキストのポータビリティの問題を引き起こしました。例えば、WindowsはCR LFを使用し、UnixはLFを使用し、クラシックMac OSはCRを使用します。Pythonは、ファイルをオープンする際に3つの一般的なラインブレークフォーマットすべてを認識する「ユニバーサルニューライン」モードを導入することで、これに対処しました。従来のCRとLFを超えて、ASCIIはFORM FEED (FF) および VERTICAL TAB (VT) も定義しており、これらもラインブレークを引き起こします。Unicodeの登場は、7つの新しいコードポイントと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が含まれます。合計で、Pythonのsplitlines()メソッドは、10個の異なるコードポイントと1つのマルチコードポイントシーケンスをラインブレークとして認識します。この包括的なセットは、テキストラインの分割を処理するための歴史的な慣習と最新のUnicode標準に対応しています。
ダークマター・エンタープライズソフトウェアという概念は、企業が構築した内部ツールで、十分に理解されておらず、しばしばそのまま放置されているものを指します。これらのツールは通常、すでに退職した個人によって構築されており、それらを変更または更新することには一般的な抵抗があります。その結果、多くの類似したツールが影の中に存在し、時間が止まったままになる可能性があります。マイケル・ブースは、大企業内の小規模チームが機能のギャップを埋めるために独自のツールを構築するハイパーチームソフトウェアのアイデアについて書いています。このアプローチは有益である可能性がありますが、適切に管理されない場合はリスクも伴います。ハイパーチームソフトウェアのアイデアは、個人の使用のために構築されたカスタマイズされたツールを指すハイパーパーソナルソフトウェアの概念の拡張です。マイケル・ブースの記事は、混沌を防ぐためのガードレールの必要性を含む、ハイパーチームソフトウェアの潜在的な利点と落とし穴を探求しています。ハイパーチームソフトウェアに関する議論は、時代遅れまたはメンテナンスの悪い内部ツールによって企業が多大な価値を失っている状況において関連性があります。このトピックは、AI支援ツールのアイデアと、小規模チームが大企業内でイノベーションを推進する可能性とも関連しています。ハイパーチームソフトウェアに関する会話は、チームが独自のツールを構築することを許可することと、問題の発生を防ぐために監視と管理のレベルを維持することとの間のバランスを見つけることの重要性を強調しています。
著者は、関数ごとの呼び出し元単位でコードカバレッジを測定したいと考えている。これは、BASICインタープリタであるAcidicaのエラーチェックコードのリファクタリングに動機づけられている。当初、各組み込み関数は独自の引数検証を持っており、エラー条件の特定のカバレッジを可能にしていた。リファクタリング後、検証が共有ヘルパー関数に移動したため、この詳細なカバレッジは失われた。提案されている解決策は、coverage.pyの動的コンテキストを活用するデコレータを含んでいる。このデコレータは、装飾された関数を実行する前に、呼び出しサイト(ファイルと行番号)にちなんで名付けられた新しいカバレッジコンテキストを作成する。関数完了時に、元のコンテキストが復元される。coverage.Coverage.current()cov.switch_context()を使用した概念実証デコレータは、この機能を示している。これには、ネストされたコンテキストをサポートするために、coverage.pyのマイナーで未リリースな変更が必要となる。著者は、HTMLカバレッジレポートがexpects関数の各呼び出し元に対して個別のコンテキストを表示し、誰がどのブランチを実行したかを明らかにしたことを発見した。将来の改善には、これらのコンテキストを後処理して特定の呼び出し元に対するカバレッジ不足を特定することや、階層的または複数のコンテキストを有効にして呼び出し元と実行詳細の両方を同時に追跡することが含まれる。著者はまた、デコレータでソースコードを変更するのではなく、coverage設定を通じてこの機能を統合することを目指している。潜在的なアプリケーションには、func_nameのような関数引数をコンテキスト識別子として使用することが含まれる。
CdXz5zHNQW_IFrCzZRuFh.png
著者は、Pandasのスキルを向上させるには、整然としたテーブルだけでなく、実際のデータで練習する必要があると強調しています。著者は、過去3年半にわたり、実際の最新の公開データに基づいた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)は複数の評価パスを集約するために使われます。テスト戦略は、チャットボットが正しい専門エージェントやスキルにプロンプトを送っているかどうかを確認する簡単なルーティング評価から始まりました。システムがツールごとのエージェントからスキルを統合したオーケストレーションエージェントへと進化するにつれ、ルーティング評価は可視性と適切なスキルの選択をチェックするよう適応しました。その後、チャットボットの完全な回答がユーザーのタスクを成功裏に完了したかを評価するために、特定のルーブリックを用いたLLMを用いてTCR評価が実装されました。これにより、プロンプトとルーブリック開発用のダイレクトモードと、全体のプロダクションパスをテストするためのプロキシモードの2つの実行モードが生まれました。また、このフレームワークは多段階の会話も扱わなければならず、テストユニットが単なるターンではなく会話全体となることもありました。これには、プロキシモードで複数のAPI通話間で会話状態を保持するか、ダイレクトモードでシミュレートする必要がありました。得点には、ステップごとのチェックや会話全体のスコアも含まれます。使用されている基盤となるテストライブラリはdeepevalであり、同社はパイプライン、プラグインシステム、CI統合、Langfuseプッシュを構築しています。ルーティングはdeepevalでカスタムの「BaseMetric」として実装され、特定のビジネスルールをLLM評価プロセスに統合する方法を示しています。
CdXz5zHNQW_2wtMsPJlJt.png