このガイドでは、fastkml Pythonパッケージをmypyからtyおよびpyreflyへ移行する方法を詳述します。tyとpyreflyの両方を同時に実行することを強調しており、これらは異なるエラーのサブセットを検出するため、単一のチェッカーよりも完全な状況を提供します。プロセスは、コード変更を行う前に両方のツールのベースラインエラー数を確立することから始まります。効率的な移行の鍵は、ファイルごとにエラーを修正するのではなく、しばしばオプションのC拡張バックエンドに関連するシステム的な根本原因を特定し、対処することにあります。ツールによって明らかになった実際のバグ、特にOptional/unionの絞り込みや位置専用スタブに関するものは修正されるべきです。テストファイルからのノイズ、「構築後に絞り込みなしでアクセス」の問題は、スコープ付きルールを使用して一括抑制されるべきです。ガイドでは、厳格なプリセットを有効にしてから特定のルールを昇格させ、過度の機械的な変更を引き起こすルールを明示的に削除することを推奨しています。検証には、両方のツールがエラーを報告しないこと、完全なテストスイートがパスすること、リンターがクリーンであることが含まれます。移行前に、tyとpyreflyが一致または上回るべき厳格さのバーを理解するために、既存のmypy構成を徹底的に分析します。mypy構成のインベントリ作成には、その設定をty/pyreflyの同等のものにマッピングし、古いモジュールごとのエラーコード無効化オーバーライドを削除することが含まれます。tyとpyreflyをインストールした後、エラーの種類別に、次にファイル別に分類されたベースラインエラー数を取得することが重要です。後者は通常、システム的な原因を明らかにします。広範な抑制を伴う部分的な移行が存在する場合は、それを警告の兆候とみなし、実際のベースラインを確認するために抑制を削除する必要があります。最も効果的な動きは、両方のチェッカーがフラグを立てるアーキテクチャの不一致を修正することです。一般的なパターンは、try/exceptインポートを介して処理されるオプションのバックエンドを含み、修正は多くの場合、型チェッカーがリッチなバックエンドのスタブを見ることができるようにするif TYPE_CHECKING:ブロックです。注意すべき点には、# type: ignore[code]コメントの移植性のなさ、pyreflyのTOMLキーの大文字/小文字の問題、インターリーブに対するpyreflyの配列テーブル構文の脆弱性、およびProtocolを具体的なクラスパラメータに直接割り当てられないことなどが含まれます。プロセス全体を通して、ツールの動作と構成の慎重な検証が不可欠です。