Programming Languages

概要 Microsoftは10月13日、.NET 11のリリース候補第2版(RC2)を公開した。RC2はGo-liveライセンスの対象となっており、本番環境での利用が推奨される段階に入った。正式リリースに向けて機能はほぼ固まり、SDK・ランタイム・ライブラリ・各フレームワークにわたって細かな改善が加えられている。SDKはget.dot.net/11から入手でき、Visual Studio 2026 InsidersやC# Dev Kit拡張を備えたVisual Studio Codeで試すことができる。 主な新機能 ライブラリ関連では、CBORデータを逐次的に読み取れる機能が追加され、大きなバイナリデータをメモリ効率よく処理できるようになった。暗号分野では、実験的なML-KEMとHPKEを組み合わせたポスト量子暗号(PQC)のコンポジット群が導入され、将来の量子コンピュータによる脅威に備えた暗号実装の検証が可能になっている。また、DataAnnotationsの検証メッセージをカスタム引数でフォーマットできるようになり、HTTP/2の同時実行性に関する初期設定も構成可能になった。 SDK側では、ファイルレベルディレクティブで引用符を扱えるようになり、launchプロファイルの引数からMSBuildプロパティを参照できるようになった。MSBuildのワイルドカードマッチング処理も高速化されている。NuGetではCLIからパッケージの最小公開年齢を設定できる機能が加わり、サプライチェーンのセキュリティ強化に資する改善となっている。 フレームワーク別の改善 .NET MAUIでは、XAMLを使わずC#だけでUIを構築できる機能が追加され、Appleのアイコンコンポーザーアセットへの対応やXAMLオーサリング・Hot Reloadの改善も行われた。ASP.NET Coreでは、QuickGridの仮想化APIが実験段階を卒業し、正式な機能として利用できるようになっている。Windows Formsではビジュアルスタイルやアクセシビリティ設定変更への反応性が向上し、フォーム表示の遅延化やKioskModeManagerコンポーネントが新たに追加された。F#ではランタイム非同期サポートと計算式内での再スロー機能が加わり、FSharp.Coreコレクションのメモリ効率やNative AOT・トリミング対応も改善されている。ランタイム面では、iOSおよびtvOS上でのファイルロック機能がデフォルトで無効化された。 今後の見通し RC2の公開によって.NET 11は正式リリースに向けた最終調整の段階に入ったとみられる。Go-liveライセンスの適用により、企業ユーザーは正式版の提供を待たずに本番環境での採用を検討できる。今回の記事では正式リリースの具体的な日付は明らかにされていないが、例年のリリースサイクルを踏まえると11月の正式公開が見込まれる。

概要 Next.jsは10月14日、帯域外(out-of-band)の緊急セキュリティアップデートを公開し、v16.4.1(Active LTS)およびv15.5.28(Maintenance LTS)をリリースした。今回の更新では、未認証のリモートコード実行(RCE)につながる重大(Critical)な脆弱性2件と、サービス拒否(DoS)につながる深刻度の高い(High)脆弱性1件が修正されている。Next.jsは広く使われるReactフレームワークであるため影響範囲が大きく、該当する機能を使用していないアプリケーションを含め、早急なアップデートが呼びかけられている。今回の更新には、依存先であるアップストリームの修正待ちのため9月のセキュリティリリースから持ち越されていた2件の修正も含まれている。 修正された脆弱性 最も深刻なのは、App RouterでCache Componentsを使用するアプリケーションにおいて、use cache関数が複数の型付き配列(typed array)を返す際に発生する未認証RCEだ(GHSA-673q-mjm6-r5xr)。関連するReact側のアップストリーム脆弱性(GHSA-xqc2-xf4c-x3h3)に起因しており、既知の回避策は存在しないため、該当する関数を持たないアプリケーションであっても直ちにアップグレードすることが推奨されている。 2つ目は、SVGを扱う際の画像最適化APIにおける未認証RCE(CVE-2026-96889 / GHSA-2464-fhr4-w9xw)だ。これは画像最適化に使われるアップストリームライブラリのメモリ関連の脆弱性に起因し、glibcベースのLinux上でNext.jsを実行している場合にリモートコード実行につながる。暫定的な回避策として、Next.jsが利用するsharpのバージョンを0.35.5以降にすることが挙げられているが、Next.js自体をパッチ済みバージョンにアップグレードすれば、パッケージマネージャーが自動的に修正済みのsharpを導入するため、根本的な対策となる。 3つ目は、Server Actionを1つ以上使用するApp Routerアプリケーションを対象としたDoS脆弱性(GHSA-p3m5-59mp-jv5r、関連するReact側のGHSA-h3gv-c5rc-p453)だ。細工されたリクエストにより過剰なCPU使用が発生し、同一プロセス内の以降のリクエスト処理がブロックされる。Pages Routerを使用している、またはServer Actionsを使用していないアプリケーションはこの脆弱性の影響を受けない。 対応方法と背景 対応は該当バージョンへのアップグレードのみで、以下のコマンドで適用できる。 npm install next@15.5.28 # 15.5系向け npm install next@16.4.1 # 16.4系向け Next.jsは、VercelがHackerOneで運営するオープンソースバグバウンティプログラムを通じて研究者と連携し、セキュリティ確保に取り組んでいる。Next.jsはVercelの主導するReactフレームワークとして多数の本番環境で採用されており、特に未認証RCEは攻撃者が認証なしにサーバー側でコードを実行できる最も深刻な部類の脆弱性であるため、影響を受ける可能性のある全ての運用者に対して速やかなパッチ適用が強く求められる。

概要 JavaScriptランタイムのBunが10月10日、v1.4.3をリリースした。最大の目玉は、標準のtscより最大6.4倍高速に動作する組み込みのTypeScript型チェッカー「bun check」だ。Microsoftが開発するGo言語版TypeScriptコンパイラ「typescript-go」をBunにポートして実装されており、bun check、bun run --check src/index.ts、bun test --checkといったコマンドで、既存のTypeScriptセットアップに統合する形で利用できる。エディタ側の型チェック処理自体には変更はない。 ベンチマークと互換性 16コアのApple Silicon Mac上での計測では、複数プロジェクトにおいてtsc 7.0.2比で処理速度が3〜6.4倍、メモリ使用量は2.2〜4.9倍少ない結果が示されたという。互換性面では、TypeScript 7.0.2のconformanceテストスイート(51,210件)を100%通過したとしており、実際のオープンソースプロジェクト72件・1,102設定で出力が完全に一致したこと、さらに136,235個の関数を対象とした大規模ファジングテストも実施したと報告している。型チェッカーという性質上、わずかな出力差異でも既存プロジェクトの挙動に影響しうるため、こうした網羅的な検証結果を前面に出している点が特徴的だ。 その他の改善点 型チェッカー以外にも、ランタイム面でいくつかの改善が加えられている。サーバーがアイドル状態にある際のCPU使用率を67〜89%削減し、不要な定期処理を抑制した。またHTTP/2では、CVE-2023-44487やCVE-2025-8671に代表されるストリームリセット攻撃への対策を実装している。新APIとして追加されたBun.FetchSessionでは、グループ化したリクエストごとに独自のTLS設定・プロキシ・コネクションプールを持たせられるようになった。 安定性面では、TLS証明書検証の強化やnode:httpのパイプライン処理・keep-alive接続周辺など、fetch()やWebSocketの信頼性向上に関わる修正が多数行われている。型チェッカーの高速化と合わせて、Node.js互換レイヤーの品質を地道に積み上げるリリースという位置づけになりそうだ。

概要 Astralが開発するPythonパッケージ/環境管理ツール「uv」のv0.13.0が、2026年10月9日にリリースされた。今回の更新で最も大きな変更点は、uvが新規にPythonをダウンロードする際のデフォルトの安定版がPython 3.14から3.15に切り替わったことだ。すでにPython 3.14がインストール済みの環境ではそのまま利用され続けるが、新規環境では3.15が優先される。既存のワークフローで3.14を使い続けたい場合は、バージョンを明示的に指定することで従来の動作を維持できる。 複数の破壊的変更 本リリースにはデフォルトPythonの変更以外にも、複数の破壊的変更が含まれている。まず、制約ファイル(constraints file)に記載された--require-hashesディレクティブの検証が厳格化され、ハッシュが不足しているパッケージのインストールは失敗するようになった。また、制約ファイル内にeditable形式（-e）の要件を記述することはエラーとして拒否されるようになり、該当する要件は通常の要件ファイルに移動する必要がある。 プラットフォーム関連では、Windows ARM64環境でネイティブのARM64インタプリタが優先的に選択されるよう改善され、これまで発生していたエミュレーションによるx86_64版の利用が減少する。加えて、Python 3.10以降の仮想環境ではdistutilsパッチ用の_virtualenv.pyファイルが削除され、起動時のオーバーヘッドが軽減された。--constraintや--overrideオプションに渡す値は単一のパスとして扱われるようになり、スペースを含むパスにも対応できるようになっている。さらに、tarアーカイブの展開処理ではより厳密な検証を行うコーデックが採用され、一部の非標準的なアーカイブ形式は拒否される点にも注意が必要だ。 パフォーマンス改善と新機能 破壊的変更に加えて、キャッシュ処理に関する複数の最適化も行われた。HTTPレスポンスの再検証が高速化され、メモリ割り当ての削減とキャッシュストレージの縮小も実現している。新機能としては、CPython 3.15.0のサポートが追加されたほか、ビルド依存関係のハッシュを検証するプレビュー機能--require-build-hashesが導入された。 影響と展望 デフォルトPythonの切り替えやeditable要件の扱いの変更は、CI環境や既存のプロジェクト設定に影響を与える可能性がある。特に制約ファイルでハッシュ検証やeditable要件を利用しているプロジェクトは、アップグレード前に設定を見直すことが推奨される。一方で、Windows ARM64のネイティブ対応強化やキャッシュ性能の改善は、Apple SiliconやARM環境でのPython開発体験の向上につながるものであり、uvがPythonツールチェイン全体のデフォルトとしての地位を強めていく流れを後押しするものと言える。

概要 Go言語の開発チームは10月8日、マイナーリリースのGo 1.27.2およびGo 1.26.9を公開した。両バージョンには、net/http、crypto/tls、net/textproto、mime/multipart、html/template、os、goコマンドなど標準ライブラリおよびツールチェインにまたがる15件のセキュリティ修正が含まれており、サーバーやツールチェインを利用する開発者には早急な更新が推奨されている。 修正された脆弱性の内容 今回の修正の中でも特に重要度が高いとされるのが、net/httpのトランスポートが複数のContent-Lengthヘッダーを受理してしまう問題で、HTTP/2経由でHTTP/1クライアントへレスポンスを転送する際にHTTPレスポンス密輸攻撃につながりうる欠陥だった。またhtml/templateでは、テンプレートリテラル式の開始位置で古いjsCtxが残留することによるXSSと、regexpPrecederKeywordsにES2015以降の予約語が含まれていないことに起因するXSSという、2件の異なるクロスサイトスクリプティング欠陥が修正されている。 ネットワーク関連では、HTTP/2サーバーが圧縮設定の変更をめぐる並行処理の不備によりクラッシュしうる問題や、トレーラー宣言を悪用したメモリ消費の肥大化、CONNECTリクエストの処理誤りによるレスポンスの誤配送、ファイル配信時のバイトレンジリクエストに関する欠陥、mime/multipartでのファイルアップロード時のメモリ上限回避、TLSハンドシェイク解析時のメモリ枯渇、HTTP/2からHTTP/1へのヘッダー変換の不備など、サービス妨害やデータ漏洩につながりうる欠陥が広範に修正された。チェックサム検証に関しても2件の欠陥が修正され、Windows環境ではosパッケージのファイルシステムジャンクションに起因する脆弱性にも対処している。 ツールチェイン側では、悪意のあるGOMODPROXYが設定された場合にgolang.org/toolchainおよびgolang.org/fips140のチェックサム検証を回避できる問題が修正された。これはビルド環境のモジュールプロキシ設定を信頼できない第三者に握られた場合、改ざんされたツールチェインやFIPS140準拠モジュールが検証をすり抜けて取り込まれる恐れがあるというもので、CI/CD環境でのGOMODPROXYの管理には引き続き注意が必要だ。 今後の対応 Go 1.27.2と1.26.9はいずれも2026年10月8日付でリリース済みで、各脆弱性の個別アドバイザリはGoの脆弱性データベースおよびGitHubの該当issueで公開されている。サーバー用途でGoを利用している開発者は、特にnet/httpのレスポンス密輸問題とhtml/templateのXSS問題について優先的に影響範囲を確認し、速やかにアップグレードすることが望ましい。

概要 Googleは10月6日、社内で10年以上使い続けてきた独自のPython型チェッカー「Pytype」を廃止し、Metaが開発したオープンソースの型チェッカー「Pyrefly」を全社の標準として採用したと発表した。背景にあるのは、Pytypeが抱えていた構造的な欠陥だ。Pytypeはソースコードではなくコンパイル済みのPythonバイトコードを解析する設計になっており、CPythonがバージョンごとにバイトコード形式を変更するたびに、Pytype側で対応のための緊急改修が必要になっていた。この負担はPython 3.11以降とくに顕著になり、Googleは最終的にPython 3.12をPytypeがサポートする最後のバージョンと位置づけ、オープンソースの代替ツールの評価に踏み切った。 PyreflyがPytypeに代わる理由 Pyreflyは、Instagramなど約2,000万行規模のPythonコードベースを抱えるMetaがRustで開発した型チェッカーで、2026年5月に v1.0 に到達している。PytypeがバイトコードをもとにPythonの型を推論していたのに対し、PyreflyはソースコードのASTを直接解析する方式を採用し、さらにRust実装によってPythonのGIL(グローバルインタプリタロック)の制約を受けずに型推論を並列化できる。この設計の違いが、大規模なモノレポでの性能差に直結した。GoogleはPyreflyの採用に際して、既存コードすべてを一度に切り替えるのではなく、評価・統合・最適化の3段階を踏み、統合の段階では動的な記述が多いコードに対するPyreflyの静的解析の課題に個別に対応していったとしている。 増分ビルドで最大98%の高速化 Googleの発表によれば、開発者が編集してリビルドするワークフロー(デーモンがウォームな状態)において、Pyreflyはターゲットによって増分ビルドのレイテンシを最大98%削減した。大規模な機械学習関連ターゲットでは、型チェックにかかる時間が分単位から秒単位へと大幅に短縮されたという。さらにクリティカルパスの処理時間は90%以上、モノレポ全体での計算リソース消費は80%以上削減されたとしており、単なる開発者体験の改善にとどまらず、Google社内のビルドインフラのハードウェアコスト削減にも直結する成果となっている。Pyrefly自身も公式の型付け適合性テストスイートで高いスコアを記録しており、Python標準の型システムへの準拠度の高さも採用を後押しした一因とみられる。 今後への影響 PyreflyはすでにPyTorchやJAXといった主要なOSSプロジェクトでも採用が進んでおり、Rustで書かれた高速な開発者ツールがPythonエコシステムの標準になっていく流れの一端を示している。長年自社ツールを使い続けてきたGoogleが、自前のPytypeを廃止してMeta製のツールへ切り替えた事実は、型チェッカーのような基盤的開発者ツールにおいても、スピードと保守性に優れたオープンソースの代替へ乗り換える合理性が高まっていることを象徴する出来事といえる。

概要 Vercelは10月6日、Next.js 16.4を正式リリースした。最大のトピックは、App Routerの新しいプログラミングモデルである「Cache Components」を、すべてのNext.jsアプリに推奨する段階に達したことだ。これまでコストやパフォーマンス面で既存モデルと同等の保証ができないケースがあったが、今回のリリースでそのギャップを埋める機能が追加され、create-next-appで作成する新規アプリではCache Componentsがデフォルトで有効になった。Cache Componentsはすでに次期メジャーバージョンのNext.js 17でデフォルト化が予定されており、16.4はその移行を本格的に進める位置づけのリリースとなる。既存アプリ向けには、AIエージェントによる移行を支援するnext upgrade --agentコマンドや専用Skillも新たに提供される。 Cache Componentsの機能強化 Cache Componentsは、コンポーネント単位で'use cache'を付与し、HTTPのCache-Controlヘッダーのようにキャッシュ可否を宣言的に制御する仕組みで、クライアント側のナビゲーションキャッシュとサーバー側キャッシュ、リクエスト時レンダリングを1つのページ内で組み合わせられる。next.config.tsでcacheComponents: trueとpartialPrefetching: trueを設定することで有効化できる。 16.4では主に2つの機能が追加された。1つはensureStaticで、ページやレイアウトに設定することで、意図しない動的コンポーネントの混入をビルド時に検出してビルドを失敗させられる。「navigation」「prefetch」「shell」の3段階で制御範囲を指定でき、ECサイトやマーケティングページなど静的性を重視するアプリでサーバーコストの肥大化を防ぐ。もう1つはnext/cacheから提供されるnavigation()・prefetch()関数で、これをawaitすることでプリフェッチ時に読み込む内容を明示的に除外し、必要なデータのみを事前取得できるようになった。メールアプリのスレッド全文のように、重いデータをリンクのプリフェッチ対象から外し、実際のナビゲーション時にのみ取得する、といった使い分けが可能になる。 AIエージェント向けツールの拡充 Next.jsチームはエージェントによる開発・保守の支援にも力を入れている。新しいnext upgrade --agentオプションは、インストール済みバージョンの確認、移行先バージョンの選定、コードモッドや検証手順の準備までをエージェントに提示し、npx next@canary upgrade --agent=latestで実行できる。さらにexperimental.agentUpgradeを設定すると、next devやnext build実行時に利用可能なアップデートをエージェントや開発者に通知する機能も追加された。デフォルトの'security'では既知の脆弱性に関するアップデートのみ通知し、'latest'では最新のメジャー・マイナーリリースへの追従を促す。加えて、experimental.agentFeedbackを有効にすると、開発中にエージェントが遭遇したフレームワークのエラーや不明瞭なドキュメントについて報告ドラフトを作成し、開発者が内容を確認・編集した上でNext.jsチームに送信できる仕組みも実験的に導入された。 パフォーマンス改善と実験的機能 Turbopack関連では、ディスクキャッシュの容量が設定変更なしで20〜25%削減された。データ本体にはZstandard圧縮を採用しつつ、メタデータは高速な参照を保つためLZ4を維持し、コンパクション処理も効率化した。また開発時は、サーバーモジュールの変更があっても表示中でないページの再コンパイルを遅延させる「Lazy server HMR」や、ランタイムを全ルートで共有する単一チャンク化により、ダウンロードサイズとキャッシュ効率が改善された。本番ビルドでもCSS Modulesのクラス名短縮やエクスポート名のマングリングにより、バンドルサイズが縮小している。さらにReact 19.3への対応により、安定版のView TransitionsやFragment Refs、新しいbrowser() APIなども利用可能になった。実験的機能としては、Rust版React Compilerの最適化対象ファイルの事前判定によるビルド高速化(Turbopack側の改善と合わせてメモリ使用量30%減・コンパイル時間15%減)、未使用の不要なコンパイル結果を削除するディスクキャッシュのガベージコレクション、クライアント側動的importの遅延コンパイル、ワーカースレッドによるツール実行の統合、シンボリックリンクされた依存関係向けの追加ルート設定、Turbopack Bundle Analyzerへのルート別サマリーやスナップショット比較機能の追加などが挙げられている。

概要 Node.jsの作者であるRyan Dahl氏が創業したDenoの開発チーム全員がCloudflareに参加することが発表された。CloudflareとDeno双方のブログで同時に公開されたこの発表によると、DenoチームはCloudflareのWorkersおよびDurable Objectsチームと合流し、分散アプリケーションのための統合プラットフォームの構築に取り組む。これに伴い、スタンドアロンのDenoランタイムは今後1年間、月次のバグ修正とセキュリティ更新のみを提供したのち公式開発を終了する。Deno Deployも、有料ユーザーをCloudflare Workersへ移行させるための6カ月の移行支援期間を経てサービスを終了する。両社は今回の統合を、スケーリングや永続状態の管理といった複雑性をインフラ側ではなくプログラミングモデル自体に組み込むための取り組みと位置づけている。 今後のスケジュールと各プロダクトの扱い 発表によれば、Denoランタイムは1年間のサポート期間後にオープンソースプロジェクトとして存続するものの、公式の開発体制は解消される。Deno Deployは6カ月以内にシャットダウンされ、既存の有料顧客にはCloudflare Workersへの移行サポートが提供される。一方、JavaScriptのパッケージレジストリであるJSRは運用を継続し、そのインフラは段階的にCloudflareの基盤へ移行される予定だ。DenoランタイムのV8バインディングであるrusty_v8も継続的にサポートされ、Cloudflareのオープンソースランタイムであるworkerdへの統合が進められる。技術面では、Ryan Dahl氏と共同創業者のBert Belder氏が、8月にリリースした分散実行基盤「celld」とworkerdの統合を主導し、Cloudflare WorkersとDurable Objectsのプログラミングモデルを自己ホスト環境でも利用可能にすることを目指すという。 背景と今後の展望 今回の統合の背景には、Denoがベンチャー資金を使い切り、次の資金調達ラウンドへの明確な道筋を描けていなかった事情があるとみられている。celldの8月のリリース時点で、業界内では事実上の買収シグナルと受け止める見方もあった。コミュニティの反応は賛否が分かれており、好意的な意見は一部にとどまる一方、今回の統合を「チームとcelldの技術を獲得するための実質的なアクハイア(acquihire)」と捉える批判的な声も目立つ。特に、独立したJavaScriptランタイムとしてNode.jsのみが残る形になることへの懸念も広がっている。本番環境でDenoを利用している開発者は、1年間のサポート期間内に移行計画を策定する必要があり、Deno依存のプロジェクトの中には代替ランタイムへの移行を検討するものも出てくるとみられる。Cloudflareにとっては、Durable Objectsが備える低コストの実行基盤や永続状態管理、WebSocket対応、高水準のJavaScriptインタフェースといった特性を、AI時代のエージェント実装向けの基盤として強化する狙いがあるとみられ、今後のWorkersプラットフォームの進化を左右する動きとして注目される。

概要 GitHubはCopilot CLI・アプリ・SDKのランタイムを、TypeScript/Node.jsからRustへと全面的に書き換えたことを明らかにした。対象となった本番コードは80万行超に及び、AIエージェントを主体とした「AI支援リライト」によって約14.5週間、128件のプルリクエストという比較的短期間で移行を完了させている。注目すべきは、この移行作業と並行して通常のリリースサイクルも維持し続けた点で、移行期間中だけで135件(安定版35件、プレリリース100件)のリリースを出荷したという。最大の成果はパフォーマンスで、クライアントの起動からシングルターンのセッション生成までの時間が5.25秒から292ミリ秒へと、約18倍に短縮された。Node.js/V8ランタイムのオーバーヘッドが解消されたことで、クライアント1つあたりのメモリ使用量も約100MB削減されている。 移行の手法とスケール 今回の移行では、TypeScript版とRust版を並行開発してある時点で切り替えるのではなく、個々のコンポーネントを段階的にRust実装へ置き換えていく漸進的な手法が採られた。移行途中はTypeScriptとRustが共存するため、両者を橋渡しする一時的なN-API相互運用レイヤーを構築。このレイヤーは移行のピーク時には内部向けN-APIエクスポート2,019件、TypeScript側の呼び出し箇所3,356か所にまで膨れ上がったが、移行完了とともに撤去されている。最終的な成果物は本番用Rustコード832,378行、Rust単体テスト468,689行という規模に達し、移行中には4,478回のcargo checkが実行され、そのうち87.1%がクリーンに完了したという。実装の大部分はAIエージェントが生成し、人間はコンパイル・テスト・レビューを担当する役割分担で進められた。新しいRustランタイムはC ABI経由の組み込み統合と、プロセス外モードの両方をサポートしており、Copilot SDK自体は引き続きTypeScript、Python、Go、.NET、Java、Rustといった言語別インターフェースを提供し続けている。 課題と今後の展望 一方でコミュニティからは、この種の大規模書き換えにおける検証の難しさを指摘する声も上がっている。特に「キャンセル処理、リトライ、バックプレッシャー」といった非同期処理まわりの挙動や、レガシーシステムに潜む「文書化されていない暗黙の動作契約」をAIエージェント主導の書き換えでどこまで正確に再現できるかが懸念点として挙げられた。大規模コードベースのAI支援移行は今後も増えていくと見られるが、今回のGitHubの事例は、段階的な置き換えと一時的な相互運用レイヤーによってリリースを止めずに大規模書き換えを完遂できることを示した一方、非決定的な振る舞いや暗黙の契約の検証という課題が依然として残ることも浮き彫りにしている。

概要 Python Software Foundationは10月9日、「Python 3.15.0」の正式版をリリースした。1,012人の貢献者による5,643件のコミットが取り込まれており、実験的なJITコンパイラの性能向上、新しい組み込み型の追加、デフォルトエンコーディングのUTF-8統一など、パフォーマンスと国際化の両面で大きな進展を含むリリースとなった。 JITコンパイラの性能向上 Python 3.13で実験的機能として導入されたJITコンパイラは、3.15で大幅にアップグレードされた。公式発表によると、x86-64 Linux環境では幾何平均で7〜8%の性能向上、AArch64macOS環境では11〜12%の高速化を達成したという。ベンチマークのアーキテクチャ間での差は大きいものの、インタプリタの根本的な高速化が着実に進んでいることを示す結果だ。これに加え、Windows 64ビット版ではテイルコール方式のインタプリタが採用され、macOS版ではフリースレッド(GILなし)ビルドがデフォルトで提供されるようになるなど、プラットフォームごとの実行基盤も強化されている。 新しい組み込み型とUTF-8統一 言語仕様面では、番兵値を明確に表現するためのsentinel型(PEP 661)と、不変な辞書を提供するfrozendict型(PEP 814)が新たに組み込み型として追加された。いずれもこれまでサードパーティライブラリやイディオムで代替されてきた機能を標準化するもので、コードの意図をより明示的に記述できるようになる。また、PEP 686に基づき、デフォルトの文字エンコーディングがUTF-8に統一された。プラットフォームやロケール設定に依存した挙動の違いを解消し、国際化対応をさらに前進させる変更となる。 プロファイリングとその他の改善 パフォーマンス分析の分野では、PEP 799により専用のプロファイリングパッケージが導入され、高周波統計サンプリングプロファイラ「Tachyon」が新たに提供される。既存のツール群を統合する形で、開発者がボトルネックを特定しやすくする狙いがある。その他にも、起動時間を短縮する遅延インポート(PEP 810)、内包表記内でのアンパッキングを可能にするPEP 798、TypedDictやTypeForm、Disjoint Basesなど型システムの拡張が盛り込まれた。なお、macOS 27.0環境ではIDLEやtkinter使用時のダイアログ関連の問題が報告されているが、これはTkフレームワーク全体に起因するOS側の問題であり、Python本体の不具合ではないとされている。