Open eli-schwartz opened 2 months ago
I don't think we should make that the default behavior for TC100, but I would be open to adding an additional setting for that. Just like we have a strictness setting for TC001/TC002/TC003.
It should be very straightforward to implement, PRs welcome.
Yup, I'd be happy to request it in .flake8 as a separate error code (and actually kinda assumed that would be preferred).
I may find time to look into implementing this myself but I cannot predict that in advance. Anyone else interested in this shouldn't bother waiting on me. :)
I'd actually prefer a setting over a separate error code, since the error message would be the same for both error codes, you're just changing the condition for when you emit the code.
TC100 helpfully warns me when files contain annotations that cannot be resolved at runtime because they were imported inside a
T.TYPE_CHECKING
block. What about files that contain annotations using builtin types (or coincidentally runtime-also types) that don't need an import?There are two advantages of future annotations:
I want both. flake8-type-checking currently helps me do the latter.
The former can kind of be done via isort --add-imports or ruff missing-required-import except that both of those are based around the notion that all files must have some arbitrary import. This causes it to demand that every empty
__init__.py
file receives that import. Also, there are sometimes files that contain pure data with trivially deducible types and don't need annotations. I figured a specialized check designed for validating annotations in the first place, might be a better place to implement such a feature.