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

Feature request: separate TYPE_CHECKING #1795

Closed
juanolon opened this issue Jul 28, 2021 · 4 comments
Closed

Feature request: separate TYPE_CHECKING #1795

juanolon opened this issue Jul 28, 2021 · 4 comments
Labels
idea_for_next_major_release wont_fix This goes beyond the current maintainers current threshold for a feature or edge case.

Comments

@juanolon
Copy link

Hello,
I was looking for a option to separate my imports, which are only for type checking from all the others, and wrap them into an if block. I look into the issues and only found this thread: #818 (comment)

It would convert this:

from torch.utils.data.dataset import Dataset
from argparse import ArgumentParser
import torch

to

if TYPE_CHECKING:
    from torch.utils.data.dataset import Dataset

from argparse import ArgumentParser
import torch

That would be huge. Thanks!

@timothycrosley timothycrosley added wont_fix This goes beyond the current maintainers current threshold for a feature or edge case. idea_for_next_major_release labels Jul 29, 2021
@timothycrosley
Copy link
Member

Hi @juanolon,

I can see why this would be useful, but unfortunately, while it may seem simple on the outside, it goes well behind what isort could reasonably support. isort only looks at, parses, and understands imports. This would require it to fully understand all syntax elements to even get it right most of the time. Even if it did that, it would still fail plenty of times, where either the import has a side effect that's intentional, or the annotation is meant for runtime (ala fastapi).

Sorry!

~Timothy

@juanolon
Copy link
Author

ic. thanks anyway!

@NeilGirdhar
Copy link
Contributor

@timothycrosley Any chance you could revisit this now that a flake8 plugin suggests putting things under type checking blocks? We would only need to support if TYPE_CHECKING, and no other constructs.

@henzef
Copy link

henzef commented Nov 30, 2022

It would be great if you could reconsider implementing this @timothycrosley. I think "require it to fully understand all syntax elements" is a bit overestimated here, because this would just need a single special case for "if TYPE_CHECKING".
The combination with the flake8 plugin as proposed by @NeilGirdhar would indeed be awesome to have!

Please also note that even mypys own detection of this is extremely simple. it doesnt even support import aliases: python/mypy#12928

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
idea_for_next_major_release wont_fix This goes beyond the current maintainers current threshold for a feature or edge case.
Projects
None yet
Development

No branches or pull requests

4 participants