snok / flake8-type-checking

Flake8 plugin for managing type-checking imports & forward references.
BSD 3-Clause "New" or "Revised" License
113 stars 16 forks source link

refactor: Create a common utility for looking up fully qualified names #194

Open Daverball opened 2 weeks ago

Daverball commented 2 weeks ago

This should make some checks a lot more robust and makes it easier to add similarly robust checks to library specific mixins.

This is also a precursor to using is_typing in the annotation visitor, so we can handle aliases and module level accesses of Literal and Annotated.

Daverball commented 2 weeks ago

Technically this implementation will allow fewer if TYPE_CHECKING: cases, since we don't unilaterally accept a TYPE_CHECKING import from any module if it's aliased or accessed through the non-typing module, but this seems fine to me (we do however still accept unqualified TYPE_CHECKING for now). If people run into issues where they have vendored TYPE_CHECKING into a different module, we can add a setting to add additional fully qualified names that should be treated as TYPE_CHECKING.

Either way this should be treated as a breaking change, but it's probably a good time for it anyways, we can drop 3.8 support and add 3.13 support at the same time.

Daverball commented 1 week ago

I added some basic handling for full name matching in the presence of star imports. I'm not fully convinced it's worth the extra complication yet, especially since they're an anti pattern and star imports may already break some of the other rules in subtle ways, we certainly don't have good test coverage for them. So I might revert this last commit again.

Daverball commented 1 week ago

Looks like ruff's current semantic model doesn't handle star imports, although I imagine they will support them, once they switch to red-knot as the backend. So I'm still neutral on adding this extra complication.

Daverball commented 1 week ago

Ruff also has a setting to specify additional typing modules, so we could do the same in order to still support vendored typing constructs (e.g. within a local compat module through local.compat .compat and ..compat to support both absolute and relative imports).