Refactor expr_to_unanalyzed_type by extracting helper functions #20196
+194
−135
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Split the 189-line `expr_to_unanalyzed_type` function into smaller, focused helper functions to improve readability and maintainability. This addresses the issue of long functions in the codebase by: - Extracting each expression type handler into a dedicated function - Maintaining identical behavior and error handling - Preserving all comments and documentation - Using descriptive function names that clarify intent Each helper function handles one expression type: - `_translate_name_expr`: Handle NameExpr (True/False/identifiers) - `_translate_member_expr`: Handle MemberExpr (dotted names) - `_translate_index_expr`: Handle IndexExpr (generic types like List[int]) - `_translate_union_op`: Handle OpExpr with | operator (X | Y unions) - `_translate_callable_argument`: Handle CallExpr for callable arguments - `_translate_list_expr`: Handle ListExpr for type lists - `_translate_unary_expr`: Handle UnaryExpr (e.g., -42) - `_translate_dict_expr`: Handle DictExpr for TypedDict literals Additional helper: - `_get_base_fullname`: Extract logic for resolving Annotated types The main function now serves as a clean dispatcher, making it easier to understand the supported expression types at a glance. All helper functions are private (prefixed with _) as they are implementation details not meant for external use. No functional changes - this is a pure refactoring to improve code organization and reduce cognitive complexity.
for more information, see https://pre-commit.ci
rchristof
changed the title
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor expr_to_unanalyzed_type by extracting helper functions
Relates to #5917
This PR addresses the long function issue by splitting
expr_to_unanalyzed_typeinto smaller, more manageable pieces.What changed
The main
expr_to_unanalyzed_typefunction was 189 lines long, which made it difficult to read and maintain. I've extracted the logic for each expression type into its own helper function:_translate_name_expr- handles name expressions (True, False, identifiers)_translate_member_expr- handles member access (a.b.c)_translate_index_expr- handles subscript expressions (List[int])_translate_union_op- handles the | operator for unions_translate_callable_argument- handles callable argument constructors_translate_list_expr- handles list expressions for type lists_translate_unary_expr- handles unary operators like -42_translate_dict_expr- handles dict expressions for TypedDict_get_base_fullname- helper for resolving Annotated typesThe main function is now 60 lines and acts as a simple dispatcher. Each helper is focused on one specific expression type.
Why this helps
analyze_ref_exprin checkexpr.py)Notes
All the new helpers are marked as private (underscore prefix) since they're internal implementation details. The public API remains unchanged.