이 가이드는 fastkml Python 패키지를 mypy에서 ty 및 pyrefly로 마이그레이션하는 과정을 상세히 설명합니다. 두 도구(ty와 pyrefly)를 동시에 실행하는 것을 강조하는데, 이는 각 도구가 서로 다른 오류 부분 집합을 감지하여 단일 검사기보다 더 완전한 그림을 제공하기 때문입니다. 이 과정은 코드 변경 전에 두 도구 모두에 대한 기준 오류 수를 설정하는 것부터 시작합니다.효율적인 마이그레이션의 핵심은 파일을 하나씩 오류를 수정하는 것이 아니라, 종종 선택적 C-확장 백엔드와 관련된 시스템적 근본 원인을 식별하고 해결하는 데 있습니다. 도구에 의해 노출된 실제 버그, 특히 Optional/union narrowing 및 positional-only stubs와 관련된 버그는 수정해야 합니다. 테스트 파일의 노이즈, 특히 "constructed-then-accessed-without-narrowing" 문제는 범위 지정 규칙을 사용하여 일괄적으로 억제해야 합니다.가이드는 엄격한 사전 설정을 활성화한 다음 특정 규칙을 승격시키고, 과도한 기계적 변경을 유발하는 규칙은 명시적으로 제거할 것을 권장합니다. 검증은 두 도구 모두 오류를 보고하지 않고, 전체 테스트 스위트가 통과하며, 린터가 깨끗한지 확인하는 것을 포함합니다. 마이그레이션 전에 기존 mypy 구성을 철저히 분석하여 ty와 pyrefly가 일치하거나 초과해야 하는 엄격성 수준을 이해해야 합니다.mypy 구성 인벤토리는 설정을 대략적인 ty/pyrefly 동등 항목에 매핑하고 오래된 모듈별 비활성화 오류 코드 재정의를 제거하는 것을 포함합니다. ty와 pyrefly를 설치한 후, 오류 종류별로, 그리고 파일별로 분류된 기준 오류 수를 얻는 것이 중요합니다. 후자는 일반적으로 시스템적 원인을 드러냅니다. 광범위한 억제를 포함하는 부분 마이그레이션이 있다면, 이는 위험 신호로 간주하고 실제 기준을 보기 위해 억제를 제거해야 합니다.가장 큰 효과를 발휘하는 조치는 두 검사기 모두에서 플래그가 지정된 아키텍처 불일치를 수정하는 것입니다. 일반적인 패턴은 try/except 임포트를 통해 처리되는 선택적 백엔드를 포함하며, 수정은 종종 타입 검사기가 더 풍부한 백엔드의 stub를 볼 수 있도록 하는 if TYPE_CHECKING: 블록입니다. 함정에는 # type: ignore[code] 주석의 이식 불가능성, pyrefly의 TOML 키 대소문자 문제, 인터리빙에 취약한 pyrefly의 array-of-tables 구문, Protocol을 직접 구체적인 클래스 매개변수에 할당할 수 없다는 점 등이 포함됩니다. 전체 과정에서 도구 동작 및 구성에 대한 신중한 검증이 필수적입니다.