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

Don't mark re-exported symbols as unused (F401) #717

Closed
layday opened this issue Nov 13, 2022 · 9 comments · Fixed by #724 or #729
Closed

Don't mark re-exported symbols as unused (F401) #717

layday opened this issue Nov 13, 2022 · 9 comments · Fixed by #724 or #729
Assignees

Comments

@layday
Copy link

layday commented Nov 13, 2022

Currently, an import in the form of:

from a import b as b

will trigger F401, but this idiom is in widespread use as a type checker-friendly alternative to __all__ which does not alter star import semantics. Type checkers which support flagging unused imports will ignore re-exported symbols, i.e. symbols where the as target is identical to the original name:

# pyright: strict

from os import environ  # Pyright reports this as unused
from os import environ as foo  # Likewise
from os import environb as environb   # No error

Thanks for ruff!

@charliermarsh
Copy link
Member

This is easy to implement! My only question is whether it should be the default behavior, or designated under its own lint rule so as to be configurable (or via a configuration option).

Anyone have opinions on that? Maybe @andersk?

@charliermarsh
Copy link
Member

I think this should be the default behavior since the re-export itself is effectively an explicit opt-in.

@andersk
Copy link
Contributor

andersk commented Nov 13, 2022

I think I agree. Although this was rejected upstream (PyCQA/pyflakes#474), it’s a pretty important pattern in the typed Python ecosystem. (Upstream is incorrect to expect that ecosystem to be entirely captured in PEPs—this reexport convention needs no special support from the Python language itself or its runtime implementations.) And I don’t see this significantly hurting anyone else.

@charliermarsh
Copy link
Member

Going out in v0.0.117 (building now).

@layday
Copy link
Author

layday commented Nov 13, 2022

whoops, I should've probably mentioned the same holds for import a as a, although not as common.

@andersk
Copy link
Contributor

andersk commented Nov 13, 2022

Also apparently import a.b.c as c. (I find that one surprising, but mypy accepts it; source.)

@charliermarsh charliermarsh reopened this Nov 13, 2022
@charliermarsh
Copy link
Member

Re-opening for those cases :)

@layday
Copy link
Author

layday commented Nov 13, 2022

Also apparently import a.b.c as c. (I find that one surprising, but mypy accepts it; source.)

Interesting, Pyright rejects that.

@andersk
Copy link
Contributor

andersk commented Nov 13, 2022

Yeah, Pyright seems more correct. Opened python/mypy#14086.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants