fix-types について
Python プロジェクトの mypy 型エラーを修正する開発スキルです。エラーを分類し、各修正案について承認を得てから進めます。型変換、実行時チェック、Django の遅延翻訳文字列の型付けにも指針を示します。
主な機能
- 01mypy による型エラーの検出
- 02エラーの分類
- 03修正ごとの承認確認
- 04type: ignore より cast() を優先
- 05必要な type: ignore の理由を記載
- 06Django 遅延翻訳型への対応
活用シーン
- 01プロジェクトの mypy エラーを段階的に修正
- 02コード変更前に型修正案を確認
- 03Django 遅延翻訳文字列に型注釈を付与
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ saaspegasus/ django-skills --skill fix-typesインストール後、Claude Code で/fix-typesを入力して読み込まれたか確認します。
詳細
あなたのタスク
型を修正するには、次の手順を実行します。
- まず型チェッカーを実行して、どのような問題があるかを確認します。
uv run mypy . - 見つかったエラーを論理的なバケットにグループ分けします。
- 各エラーのバケットについて、エラーを1つずつ確認し、適用したい修正を伝えてから、進める前に質問や提案があるかどうかを尋ねてください。
- 承認を得た後にのみ、修正を適用し、バケット内の次のエラーに進みます。
- バケットを完了したら、次のバケットに進んでよいかどうかを尋ねてください。
type: ignore よりも cast() を優先する
mypy が正しい型を推論できない場合は、# type: ignore よりも cast() の使用を優先してください。
# Preferred - documents the expected type
choices = cast(list[tuple[str, str]], field.choices)
# Avoid when cast is possible - just silences the error
choices = list(field.choices) # type: ignore[arg-type]
理由: cast() は期待する型を明示的に文書化するため、コードがより読みやすく保守しやすくなります。また、同じ行にある他の潜在的なエラーを抑制することもありません。
null チェックにはアサーションよりも適切なエラーを優先する
mypy を満たすために null チェックを追加する場合は、assert を使用するよりも適切な例外を送出することを優先してください。
# Preferred - proper error handling
if obj.related_field is None:
raise ValueError("Object must have a related field")
result = obj.related_field.some_method()
# Avoid - assertions can be disabled with -O flag
assert obj.related_field is not None
result = obj.related_field.some_method()
理由: アサーションは本番環境で python -O を指定すると無効化される可能性があり、実行時の検証には信頼できません。適切な例外を使用すれば、チェックが常に実行され、より優れたエラーハンドリングを提供できます。
type: ignore を使用する場合はコメントを追加する
type: ignore が必要な場合(例: 有効なコードに対する mypy の制限)は、常に短い説明を追加してください。
# Good - explains why the ignore is needed
self.tier = tier # type: ignore[misc] # mypy can't handle Enum tuple values with custom __init__
# Bad - no explanation
self.tier = tier # type: ignore[misc]
Django の遅延翻訳文字列の型ヒント
Django の遅延翻訳文字列(gettext_lazy)で型ヒントを使用する場合は、次のパターンを使用して mypy のエラーを回避しつつ、本番環境(django-stubs-ext がインストールされていない環境)でもコードが動作するようにしてください。
from __future__ import annotations # Must be the first import
from typing import TYPE_CHECKING
if TYPE_CHECKING:
from django_stubs_ext import StrOrPromise
# Then use StrOrPromise in type hints
def my_function(name: StrOrPromise) -> StrOrPromise: ...
class MyData:
title: StrOrPromise
description: StrOrPromise
このパターンを使用する理由:
from __future__ import annotationsにより、型アノテーションは実行時には文字列になります(評価されません)if TYPE_CHECKING:により、インポートは型チェック時のみ行われ、実行時には行われませんdjango-stubs-extは開発用依存関係であり、本番環境では利用できません- このパターンにより、通常の文字列と遅延翻訳文字列の両方を受け入れられます
コメント
Markdown 対応