Context
During review of #657, it was noted that DEFAULT_TEST_TYPE in common/types.py lacks a Final annotation, while VALID_TEST_TYPES and BASE_CLASS_MAPPING in test_type_resolver.py do use Final.
Looking at the broader codebase, none of the constants in core/constants.py or other modules use Final — only test_type_resolver.py does. Adding Final to just DEFAULT_TEST_TYPE would widen rather than narrow the inconsistency.
Discussion
Should we:
- Add
Final to all module-level constants across the codebase (systematic, but potentially noisy)
- Remove the existing
Final annotations from test_type_resolver.py to match the rest of the codebase
- Leave as-is — the value of
Final for simple constants may not justify the annotation overhead
Factors to consider:
- mypy already catches most reassignment issues through other type checks
Final adds value mainly for constants that could be confused with mutable variables
- Consistency within the codebase matters more than following a theoretical best practice
References
Context
During review of #657, it was noted that
DEFAULT_TEST_TYPEincommon/types.pylacks aFinalannotation, whileVALID_TEST_TYPESandBASE_CLASS_MAPPINGintest_type_resolver.pydo useFinal.Looking at the broader codebase, none of the constants in
core/constants.pyor other modules useFinal— onlytest_type_resolver.pydoes. AddingFinalto justDEFAULT_TEST_TYPEwould widen rather than narrow the inconsistency.Discussion
Should we:
Finalto all module-level constants across the codebase (systematic, but potentially noisy)Finalannotations fromtest_type_resolver.pyto match the rest of the codebaseFinalfor simple constants may not justify the annotation overheadFactors to consider:
Finaladds value mainly for constants that could be confused with mutable variablesReferences