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

[red-knot] respect TYPE_CHECKING even if not imported from typing #15722

Open
carljm opened this issue Jan 24, 2025 · 2 comments
Open

[red-knot] respect TYPE_CHECKING even if not imported from typing #15722

carljm opened this issue Jan 24, 2025 · 2 comments
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented Jan 24, 2025

Description

In order to avoid the runtime cost of importing typing module, some users use a pattern like this:

TYPE_CHECKING = False
if TYPE_CHECKING:
    from typing import ...

Where the type checker should recognize the name TYPE_CHECKING and treat it as True for type checking. Mypy and pyright both support this.

This is of course a bit ugly because we're recognizing an arbitrary name wherever it's used, but in practice the name is so distinctive that this doesn't seem to cause a lot of trouble.

It can be supported in a general way with a config option that allows specifying arbitrary names that should always be considered as builtin constants with some type, but this isn't usable for a library that can't control its users' type checker configuration.

Ideally we would specify a more principled way to do this (though that might also not be practically worth the community churn.)

But the use case is valid, and we should support it the same way pyright and mypy do, to avoid adding a migration barrier.

@brandonsorensen
Copy link

Can this issue be closed now that #15719 is merged?

@MichaReiser
Copy link
Member

This issue is for red-knot, our new type checker. It's separate from Ruff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

No branches or pull requests

3 participants