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

Should black remove unused imports? #86

Closed
MichalPodeszwa opened this issue Mar 29, 2018 · 9 comments
Closed

Should black remove unused imports? #86

MichalPodeszwa opened this issue Mar 29, 2018 · 9 comments
Labels
R: rejected This will not be worked on T: enhancement New feature or request T: style What do we want Blackened code to look like?

Comments

@MichalPodeszwa
Copy link

I've noticed that right now Black doesn't do that.
I'm wondering whether it's something that Black should take care of?

@eplaut
Copy link

eplaut commented Mar 29, 2018

+1

@Lukas0907
Copy link

There is already a tool that does that, btw.: https://github.com/myint/autoflake

@ambv
Copy link
Collaborator

ambv commented Mar 29, 2018

I'm afraid this is scope creep and something that can silently break otherwise valid programs. My intuition is to avoid this in Black.

@ambv ambv added T: enhancement New feature or request R: rejected This will not be worked on T: style What do we want Blackened code to look like? labels Mar 29, 2018
@ambv ambv closed this as completed Mar 29, 2018
@wyuenho
Copy link

wyuenho commented Jul 26, 2020

Javascript has the same issue and Prettier doesn't seem to have the same qualm in removing unused imports and vars by default. Is there anything special in Python that you can't do with ES modules?

@ichard26
Copy link
Collaborator

ichard26 commented Jul 26, 2020

Imports has some weird side effects sometimes that would probably be really hard to detect statically. See the example here
#333 (comment). The example is a valid set of instructions per se, but it depends on an side effect of importing. Even if pkg.mod2 doesn't seemed to be used, it is needed so the REPL can access pkg.mod which is imported via pkg.mod2.

@wyuenho
Copy link

wyuenho commented Jul 27, 2020

I see. I guess __all__ = [foo, bar] will also make it hard too, since now you have to chase an entire graph to dereference the values too.

@hadialqattan
Copy link
Contributor

hadialqattan commented Oct 3, 2020

Imports has some weird side effects sometimes that would probably be really hard to detect statically. See the example here
#333 (comment). The example is a valid set of instructions per se, but it depends on an side effect of importing. Even if pkg.mod2 doesn't seemed to be used, it is needed so the REPL can access pkg.mod which is imported via pkg.mod2.

I agree with you!

BTW, I've developed a tool to do this task safely, If you are interested please check it out!

Docs: https://hadialqattan.github.io/pycln
Repo: https://github.com/hadialqattan/pycln

@Danipulok
Copy link

Danipulok commented Nov 9, 2022

@ambv is there any example the program could silently break because of unused imports?
Even PyCharm highlights unused imports. And when you need them, can use # noqa (as I and many developers do).
Is there any way you could implement the same logic?

Or at least do it with a specified flag that's disabled by default. In my opinion, it would be really useful.

@ichard26
Copy link
Collaborator

An example off the top of my head: readline is a stdlib module commonly used as simply an import. By importing it, history is enabled for input() prompts.

[...] it would be really useful.

Yes it would be useful, but I don't believe this is in scope for Black. Black's focus is code style, not code optimization or linting. Other tools can and should handle those; I don't want to be in the business of writing an autofixer for linting issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R: rejected This will not be worked on T: enhancement New feature or request T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

8 participants