mypy — правило для Cursor: проверки типов и установка
Правило задаёт рекомендации по настройке mypy и аннотациям Python. Оно пригодится, если вы хотите находить ошибки типов до запуска кода.
.cursor/rules/mypy.mdcЧто делает mypy
Правило применяется к файлам **/*.py. Оно рекомендует хранить настройки mypy в pyproject.toml, закреплять версию проверяющего инструмента и подключать проверки к CI или pre-commit. Для существующего проекта предлагается начать с мягких настроек и постепенно включать строгие проверки.
В рекомендациях разобраны аннотации: использовать object вместо Any, объявлять псевдонимы типов через TypeAlias, применять | для объединений и встроенные обобщённые типы. Для структурной типизации предлагается Protocol, а для подавления ошибок — комментарий # type: ignore с кодом ошибки. В крупных проектах правило советует запускать dmypy для инкрементальных проверок.
При установке в Cursor поместите файл по пути .cursor/rules/mypy.mdc. Версию mypy нужно закрепить в настройках проекта; библиотеки без заглушек типов потребуют установки или создания таких заглушек.
Какие задачи решает
- настроить mypy через
pyproject.toml - постепенно включить строгие проверки в существующем проекте
- заменить
Anyи старые формы аннотаций более точными типами - подавлять отдельные ошибки mypy с указанием кода
- проверять типы библиотек без заглушек
Примеры запросов агенту
- Проверь типы в этом Python-файле и предложи правки по правилу mypy.
- Настрой mypy в
pyproject.tomlдля постепенного включения строгих проверок. - Замени широкие аннотации в этом модуле и укажи конкретные коды для нужных
# type: ignore.
Как установить mypy
Вручную: положить файлы
.cursor/rules/mypy.mdcВо frontmatter: description, globs, alwaysApply
Вручную: положить файлы
.claude/rules/mypy.mdПоле paths во frontmatter ограничивает файлы: globs из источника → paths
AGENTS.md
Codex читает AGENTS.md: вставьте текст правила туда
Вручную: положить файлы
.github/instructions/mypy.instructions.mdПоле applyTo задаёт, к каким файлам применять: globs из источника → applyTo
Вручную: положить файлы
.devin/rules/mypy.mdВручную: положить файлы
.clinerules/mypy.mdПо шагам, с командами для каждой платформы: Cursor rules: файлы .mdc, четыре режима и замена .cursorrules
Вопросы о mypy
Как установить mypy в Cursor?
Добавьте правило в .cursor/rules/mypy.mdc. Оно будет применяться к Python-файлам, соответствующим шаблону **/*.py.
Что делает правило mypy?
Оно задаёт рекомендации по конфигурации mypy, аннотациям Python и разбору ошибок типов. Также описывает применение dmypy и работу с заглушками сторонних библиотек.
Как подключить mypy к существующему проекту?
Начните с минимальной конфигурации в pyproject.toml, затем включайте более строгие проверки по модулям или для всего проекта. Версию mypy рекомендуется закрепить.
Исходный текст
mypy.mdc · CC0-1.0
---
description: This guide provides definitive, actionable best practices for using mypy to ensure robust static type checking in Python projects, focusing on modern patterns and common pitfalls.
globs: **/*.py
---
# mypy Best Practices
mypy is the definitive static type checker for Python. Adhering to these guidelines ensures your codebase is robust, maintainable, and catches type errors before runtime.
## 1. Configuration & Integration
Always use a shared `pyproject.toml` for mypy configuration. This ensures consistency across the team and CI/CD. Pin your mypy version.
### 1.1. Centralized Configuration
**Always** configure mypy via `pyproject.toml`. This is the modern standard.
❌ BAD: `mypy.ini` or command-line flags only
✅ GOOD: `pyproject.toml`
```toml
# pyproject.toml
[tool.mypy]
python_version = "3.11"
warn_unused_ignores = true
disallow_untyped_defs = true
disallow_incomplete_defs = true
check_untyped_defs = true
no_implicit_optional = true
strict_optional = true
warn_redundant_casts = true
warn_return_any = true
warn_unreachable = true
# Enable strict mode for new code, or specific modules
# strict = true
```
### 1.2. CI/CD & Pre-commit Hooks
Integrate mypy into your CI/CD pipeline and as a pre-commit hook. Catch errors early.
```bash
# .pre-commit-config.yaml
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0 # Use the latest stable version
hooks:
- id: check-added-large-files
- id: check-yaml
- id: end-of-file-fixer
- id: trailing-whitespace
- repo: https://github.com/pre-commit/mirrors-mypy
rev: v1.8.0 # Pin to the same version as your pyproject.toml
hooks:
- id: mypy
args: [--no-strict-optional, --ignore-missing-imports] # Override global strict for pre-commit if needed
```
### 1.3. Incremental Adoption
For existing codebases, start with a minimal configuration and gradually enable stricter checks. Prioritize annotating widely imported modules.
```toml
# pyproject.toml (initial, less strict)
[tool.mypy]
python_version = "3.11"
ignore_missing_imports = true # Temporarily ignore missing stubs
allow_untyped_defs = true # Allow unannotated functions
```
Then, enable stricter checks module by module or globally.
## 2. Type Hinting Best Practices
### 2.1. Prefer `object` over `Any`
Use `object` when a function truly accepts any value, especially for arguments. `Any` disables type checking.
❌ BAD:
```python
def process_data(data: Any) -> None:
print(str(data))
```
✅ GOOD:
```python
def process_data(data: object) -> None:
# mypy knows 'data' is an object, but not its specific type
print(str(data))
```
### 2.2. Use `TypeAlias` for Type Aliases
Explicitly declare type aliases with `TypeAlias` for clarity.
❌ BAD:
```python
Vector = list[float]
```
✅ GOOD:
```python
from typing import TypeAlias
Vector: TypeAlias = list[float]
```
### 2.3. Concrete vs. Abstract Types
For arguments, prefer abstract types (protocols, ABCs) for flexibility. For return values, prefer concrete types for clear implementation.
❌ BAD (arguments too specific, returns too abstract):
```python
from typing import MutableMapping
def map_data(input: list[str]) -> MutableMapping[str, int]:
return {s: len(s) for s in input}
```
✅ GOOD:
```python
from collections.abc import Iterable
def map_data(input: Iterable[str]) -> dict[str, int]:
"""Maps strings to their lengths."""
return {s: len(s) for s in input}
```
### 2.4. Shorthand Union Syntax
Use `|` for unions and `None` as the last element.
❌ BAD:
```python
from typing import Union, Optional
def get_item(key: Union[str, int]) -> Optional[str]:
...
```
✅ GOOD:
```python
def get_item(key: str | int) -> str | None:
...
```
### 2.5. Built-in Generics
Use built-in generic types (`list`, `dict`, `set`) instead of `typing` aliases.
❌ BAD:
```python
from typing import List, Dict
def process_items(items: List[str]) -> Dict[str, int]:
...
```
✅ GOOD:
```python
def process_items(items: list[str]) -> dict[str, int]:
...
```
### 2.6. Protocols for Structural Typing
Define interfaces with `Protocol` for robust duck typing.
```python
from typing import Protocol
class SupportsQuack(Protocol):
def quack(self) -> str:
...
def make_it_quack(duck: SupportsQuack) -> None:
print(duck.quack())
class MyDuck:
def quack(self) -> str:
return "Quack!"
make_it_quack(MyDuck()) # ✅ Works, MyDuck implicitly satisfies SupportsQuack
```
## 3. Managing Type Errors
### 3.1. Specific `# type: ignore`
Only use `# type: ignore` as a last resort, always with a specific error code, and review regularly.
❌ BAD:
```python
result = some_untyped_function() # type: ignore
```
✅ GOOD:
```python
result = some_untyped_function() # type: ignore[no-untyped-call]
```
### 3.2. Strict Mode for New Code
Enable `strict = true` in `pyproject.toml` for all new modules or the entire codebase once mature.
```toml
# pyproject.toml
[tool.mypy]
strict = true
```
## 4. Performance Considerations
Use the mypy daemon (`dmypy`) for faster incremental checks in large codebases.
```bash
# Start the daemon once
dmypy start
# Run checks repeatedly
dmypy run -- foo.py bar.py
# Stop the daemon when done
dmypy stop
```
## 5. Third-Party Libraries
For libraries without type stubs, install community stubs or generate your own.
```bash
# Install community stubs
mypy --install-types
```
© sanjeed5 · CC0-1.0 · sanjeed5/awesome-cursor-rules-mdc