# mypy: comments. Inline configuration takes the highest precedence over all other configuration mechanisms.
File-level configuration
Place configuration comments at the top of a file to apply settings to the entire file.Configuration comment format
Inline configuration follows these rules:Flag names
Flags correspond to config file flags but allow hyphens to be substituted for underscores.Values
Values are specified using=, but = True may be omitted for boolean flags:
Multiple flags
Separate multiple flags with commas or place them on separate lines:Inverting options
Boolean options can be inverted by addingno- or swapping disallow/allow prefixes:
Line-level type ignores
Use# type: ignore comments to suppress errors on specific lines.
Basic type ignore
Error code-specific ignores
Specify error codes to ignore only specific errors:Using error code-specific ignores is recommended to avoid accidentally suppressing other errors.
Common inline configurations
Disabling type checking for a file
Enabling strict mode for a file
Module-specific import handling
Adjusting error codes
Supported options
Most configuration file options are supported inline. However, some restrictions apply:Not supported in inline config
Not supported in inline config
These options cannot be used in inline configuration:
python_version- Must be set globallystrict- Not supported inline; use individual flags instead- Report generation options (
any_exprs_report,html_report, etc.)
Per-module options
Per-module options
These options are commonly used inline:
ignore_errorsignore_missing_importsfollow_importsdisallow_untyped_defsdisallow_untyped_callscheck_untyped_defswarn_return_anywarn_unused_ignoresenable_error_codedisable_error_code
Configuration precedence
Inline configuration has the highest precedence:- Inline configuration (
# mypy:comments) - Highest precedence - Per-module configuration sections (most specific pattern)
- Per-module configuration sections (less specific patterns)
- Command-line options
- Global configuration file options - Lowest precedence
Best practices
Use error code-specific ignores
Use error code-specific ignores
Always specify error codes when using This prevents accidentally suppressing other errors.
# type: ignore:Document why you're ignoring errors
Document why you're ignoring errors
Add explanatory comments when using type ignores:
Prefer configuration files for project-wide settings
Prefer configuration files for project-wide settings
Use inline configuration for file-specific overrides, not project-wide settings:
Use inline config for incremental adoption
Use inline config for incremental adoption
When gradually adding types to a codebase, use inline configuration to enable strict checking on new/refactored files: