Open Daverball opened 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.
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.
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.
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).
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 ofLiteral
andAnnotated
.