unstructured-dict-access-where-model-exists
Function reads a value via string-key subscript / .get(...) chains whose key set matches a Pydantic / dataclass / TypedDict already defined in this project.
Applies to: Python
Why this matters
When the canonical shape for a value already exists as a typed model in the repo, accessing it through `d['key']` and `d.get('key')` throws away every guarantee the model provides. A typo in the key string is silent until runtime; a field rename in the model leaves the dict-access callers stale; pyright / IDE rename / find-references all stop working at the boundary. Validate the dict at the boundary (`Model.model_validate(raw)` for Pydantic, `Model(**raw)` for dataclass) and use attribute access downstream.
Catch it before it ships
pip install stablestack # or: npx stablestackstablestack # scans your project, TYPE017 includedstablestack explain TYPE017TYPE017 is part of the Pro rule set. See pricing — the free tier ships 24 checks with no signup.
False positive in your codebase? Suppress a single line with # noqa: TYPE017
More Type Safety checks
weak-typing
Weak typing pattern (Dict[str, Any], List[Any]) loses type safety.
TYPE002naked-dict-for-structured-data
Using plain dict for structured data instead of dataclass/TypedDict.
TYPE004missing-type-hints
Function is missing type hints.
TYPE005inline-type-definition
Inline type definition instead of using shared/generated types.
TYPE006dict-type-inconsistency
Dict return type annotation doesn't match actual value types being assigned.
TYPE007duplicate-type-definition
Type definition may be duplicated across files.
TYPE008typescript-any
Explicit 'any' type defeats TypeScript's type safety
TYPE009env-non-null-assertion
Non-null assertion on env vars can cause runtime crashes