Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require __future__.annotations for all files with type annotations, not just for forward references #190

Open
eli-schwartz opened this issue Sep 6, 2024 · 3 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@eli-schwartz
Copy link

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:

  • it avoids the runtime cost of evaluating them
  • it avoids the runtime fatal error of evaluating them when they cannot be evaluated

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.

@Daverball
Copy link
Collaborator

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.

@eli-schwartz
Copy link
Author

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. :)

@Daverball
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants