astral-sh / ruff

An extremely fast Python linter and code formatter, written in Rust.
https://docs.astral.sh/ruff
MIT License
32.81k stars 1.1k forks source link

[flake8-type-checking] Add include-modules option (Feature Request) #13428

Open gregbrowndev opened 1 month ago

gregbrowndev commented 1 month ago

Hi, thank you for the work on ruff and lint/auto-fix rules!

I've added the flake8-type-checking (TCH) rules to my codebase to automatically move type-only imports to an if TYPE_CHECKING block. Super helpful to build lean, production images without superfluous type-shed libraries.

Ruff allows me to disable the TCH001 and TCH003 rules to ignore first-party and standard library type-only imports. However, the TCH002 rule treats all third-party typing-only imports the same. Since some third-party libraries ship with type annotations, these are available in the production build. These types could be imported directly and avoid the additional stringified, forward references throughout the code.

I feel this would be a smaller migration step for teams to introduce, easing the experience for people less familiar with type hints (since IMO the quotes do add some additional visual clutter).

I've used the exempt-modules option to exclude common third-party libraries so they can be imported directly, but it would be simpler to specify specifically which third-party libraries to fix, i.e., the type shed ones.

Thanks a lot

MichaReiser commented 1 month ago

Thanks for the kind words.

I'm not sure if I fully understand what you're asking for.

avoid the additional stringified, forward references throughout the code.

From reading TCH002's documentation, I understand that the rule doesn't stringify type annotations. It only does so for a few or when [lint.flake8-type-checking.quote-annotations](https://docs.astral.sh/ruff/settings/#lint_flake8-type-checking_quote-annotations) is enabled. Could you share an example with your configuration where the type annotations get stringified?

I've used the exempt-modules option to exclude common third-party libraries so they can be imported directly, but it would be simpler to specify specifically which third-party libraries to fix, i.e., the type shed ones.

I prefer excempt-modules. Yes, it's more annoying to set up initially because it requires listing all modules, but it prevents a new module from accidentally "slipping" through. Maybe you don't want to exclude that new module because you decide to use deferred type annotations for all imports from that new module, there's no existing code after all.

The other reason I prefer excempt-modules is because the main motivation of TCH002 is to reduce the runtime overhead of importing typing only modules at runtime. Only including few modules defeats the purpose of the rule, IMO.