home / skills / gigaverse-app / skillet / pythonista-typing

pythonista-typing skill

/pythonista/skills/pythonista-typing

This skill helps you implement precise type hints and Pydantic models to fix type errors and improve code clarity.

npx playbooks add skill gigaverse-app/skillet --skill pythonista-typing

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
4.2 KB
---
name: pythonista-typing
description: Use when adding type hints, fixing type checker errors, working with Pydantic models. Triggers on "type", "types", "typing", "Pydantic", "BaseModel", "pyright", "basedpyright", "mypy", "type error", "type hint", "annotation", "Any", "dict", "list", "Optional", "Cannot assign", "Incompatible types", "Missing return type", "reportArgumentType", or when defining function signatures or data models.
---

# Type Annotations and Pydantic Best Practices

## Core Philosophy

**Use Pydantic models for structured data. Use specific types everywhere. Never use `Any` or raw dicts when structure is known.**

## Quick Start - Fixing Type Errors

```bash
# 1. Run type checker
pyright <file-or-directory>
# or
basedpyright <file-or-directory>

# 2. Fix errors (see patterns below and reference files)

# 3. Verify no behavior changes
pytest tests/
```

## Fix Priority Order

1. **Add proper type annotations** (Optional, specific types)
2. **Fix decorator return types**
3. **Use `cast()`** for runtime-compatible but statically unverifiable types
4. **Last resort: `# type: ignore`** only for legitimate cases

## Type Annotation Rules

### Modern Python Syntax (3.9+)

```python
# CORRECT
def process_data(items: list[str]) -> dict[str, list[int]]:
    results: dict[str, list[int]] = {}
    return results

# WRONG - Old style
from typing import Dict, List
def process_data(items: List[str]) -> Dict[str, List[int]]:
    ...
```

### NEVER Use Weak Types

```python
# NEVER
items: list[Any]
data: dict
result: Any

# ALWAYS use specific types
items: list[DataItem]
data: dict[str, ProcessedResult]
result: SpecificType | OtherType
```

### NEVER Use hasattr/getattr as Type Substitutes

```python
# WRONG - Type cop-out
def process(obj: Any):
    if hasattr(obj, "name"):
        return obj.name

# CORRECT - Use Protocol
class Named(Protocol):
    name: str

def process(obj: Named) -> str:
    return obj.name
```

### Complex Return Types Must Be Named

```python
# WRONG - Unreadable
def execute() -> tuple[BatchResults, dict[str, Optional[Egress]]]:
    pass

# CORRECT - Named model
class ExecutionResult(BaseModel):
    batch_results: BatchResults
    egress_statuses: dict[str, Optional[Egress]]

def execute() -> ExecutionResult:
    pass
```

**Rule**: If you can't read the type annotation out loud in one breath, it needs a named model.

## Pydantic Rules

### Always Use Pydantic Models for Structured Data

```python
# WRONG - Raw dict
def get_result() -> dict[str, Any]:
    return {"is_valid": True, "score": 0.95}

# CORRECT - Pydantic model
class Result(BaseModel):
    is_valid: bool
    score: float

def get_result() -> Result:
    return Result(is_valid=True, score=0.95)
```

### TypedDict and dataclasses Are Prohibited

**NEVER use TypedDict or dataclasses without explicit authorization. Always use Pydantic.**

### Never Convert Models to Dicts Just to Add Fields

```python
# WRONG - Breaking type safety
result_dict = result.model_dump()
result_dict["_run_id"] = run_id  # Now untyped!

# CORRECT - Extend the model
class ResultWithRunId(BaseModel):
    details: ResultDetails
    run_id: str | None = None
```

## Prefer cast() Over type: ignore

```python
from typing import cast

# Preferred
typed_results = cast(list[ResultProtocol], results)
selected = select_by_score(typed_results)

# Less clear
selected = select_by_score(results)  # type: ignore[arg-type]
```

## When to Use type: ignore

Only for:
1. Function attributes: `func._attr = val  # type: ignore[attr-defined]`
2. Dynamic/runtime attributes not in type system
3. External library quirks (protobuf, webhooks)
4. Legacy patterns requiring significant refactoring

DO NOT use for simple fixes (add Optional, fix return types).

## Reference Files

For detailed patterns:
- [references/pydantic-patterns.md](references/pydantic-patterns.md) - Pydantic patterns and external system integration
- [references/expanding-coverage.md](references/expanding-coverage.md) - How to add new modules to type checking

## Related Skills

- [/pythonista-testing](../pythonista-testing/SKILL.md) - Testing typed code
- [/pythonista-reviewing](../pythonista-reviewing/SKILL.md) - Type issues in code review
- [/pythonista-async](../pythonista-async/SKILL.md) - Async type patterns

Overview

This skill helps add precise type hints, resolve type checker errors, and design Pydantic models for structured data. It enforces using specific types instead of Any or raw dicts and promotes modern Python typing syntax. Followed correctly, it reduces runtime surprises and makes static checks like pyright and mypy reliable. The skill also prescribes when to use cast() and when type: ignore is acceptable.

How this skill works

It inspects function signatures, return annotations, decorator types, and data model definitions to find weak or missing types. It suggests converting raw dicts and TypedDict/dataclasses into Pydantic BaseModel classes and splitting complex anonymous return types into named models. When static verification is impossible, it prefers cast() over broad type: ignore, and it enforces a clear priority for fixes: add annotations, fix decorators, use cast, then type: ignore as last resort.

When to use it

  • Adding or refining type hints across a codebase
  • Fixing pyright, basedpyright, or mypy errors
  • Designing or refactoring data models into Pydantic BaseModel
  • Defining complex function return types that are hard to read
  • Reviewing code that uses Any, raw dicts, TypedDict, or dataclasses for structured data

Best practices

  • Prefer Pydantic models for any structured data; avoid raw dicts and TypedDict/dataclasses unless explicitly authorized
  • Use modern typing syntax (list[str], dict[str, int], X | None) for Python 3.9+
  • Never use Any as a shortcut; prefer concrete types or a Protocol where appropriate
  • If a type is too complex to read in a breath, name it as a model or dataclass-equivalent Pydantic model
  • Use cast() to bridge runtime-compatible but statically unverifiable types; reserve type: ignore only for legitimate runtime quirks

Example use cases

  • Fixing 'Incompatible types' errors from pyright by adding precise return annotations
  • Converting API response dicts into Pydantic BaseModel classes for safer downstream code
  • Replacing hasattr/getattr heuristics with Protocols or proper typed models
  • Breaking a large, nested tuple/dict return into a named ExecutionResult model
  • Applying cast() when a third-party library returns an imprecise type that is known safe

FAQ

When is type: ignore acceptable?

Only for runtime attributes, external library quirks, or legacy patterns that require extensive refactor. Do not use it for simple fixes that should be solved by proper annotations.

Should I use TypedDict or dataclasses?

No—prefer Pydantic BaseModel for structured data unless you have explicit authorization to use TypedDict or dataclasses.