Add a generic is_module_member function in pylint.checkers.utils - #11294
Add a generic is_module_member function in pylint.checkers.utils#11294Pierre-Sassoulas wants to merge 1 commit into
is_module_member function in pylint.checkers.utils#11294Conversation
363ea63 to
6d4cd02
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #11294 +/- ##
==========================================
+ Coverage 96.41% 96.43% +0.02%
==========================================
Files 178 178
Lines 20068 20055 -13
==========================================
- Hits 19348 19340 -8
+ Misses 720 715 -5
🚀 New features to boost your workflow:
|
This comment has been minimized.
This comment has been minimized.
is_module_member function in pylint.checkers.utils
3018a36 to
9807f61
Compare
This comment has been minimized.
This comment has been minimized.
Three helpers each answered that question their own way for the 'typing' module, and 'is_sys_guard' answers a fourth version of it for 'sys' by matching the spelling. is_module_member takes the module name and the members as arguments, so the answer lives in one place: - is_typing_member was that call with "typing" filled in, so it delegates rather than repeat the two lookups. It stays as it is public API. - in_type_checking_block spelled out both branches by hand. Its 'TYPE_CHECKING = False' fallback is kept, still scoped to that one name so an unrelated flag inferring to False does not pass for a type-checking guard. - uninferable_final_decorators spent 30 lines reaching an import node to ask whether a decorator is typing.final. It asks directly now, which drops the 'import_node.modname' read that would raise an AttributeError on a nodes.Import, reachable through the '@Final' bound by 'import final'. Resolving the module through 'lookup' rather than through inference is what lets one helper serve all of them: inference comes up empty when the import itself sits inside a guarded block, which the sys version guards need, and it is also what tells a class named after a module apart from the module. So all three gain an aliased 'from typing import TYPE_CHECKING as TC', an 'import typing' that sits inside a block, every binding of a name rather than only the first, and a 'class typing' that no longer passes for the module. None of that shows up in practice: across five primer packages, 158130 nodes sitting directly inside an 'if' get the same in_type_checking_block verdict as before. 'is_sys_guard' is left alone here; it is rewritten on top of this in its own commit.
9807f61 to
5db503e
Compare
|
|
🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉 This comment was generated for commit 5db503e |
Type of Changes
Description
Groundwork split out of #11293, which needs the same question answered for
sysand reads much smaller once this lands.
I tried some design first
(node, modname, *members: str)and(node, modname, members: tuple[str, ...]), but I think *qnames is the easier to understand.Refs #11293