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 move imports under if TYPE_CHECKING if they're added to __all__ #6236

Closed
pawamoy opened this issue Aug 1, 2023 · 3 comments
Closed

Comments

@pawamoy
Copy link

pawamoy commented Aug 1, 2023

In my top-level __init__.py file, I define the __all__ variable to mark some imported objects as "public" or "re-exported".

from __future__ import annotations

from pkg.submodule import A, B, C

__all__: list[str] = ["A", "B", "C"]

When auto-fixing this code with Ruff 0.0.281, Ruff moves all imports under an if TYPE_CHECKING condition, probably because they appear unused, and because I import annotations from __future__ . If I don't import future annotations, Ruff does not refactor the code (I'm targeting Python 3.8).

Moving these public imports under the TYPE_CHECKING condition actually breaks the API, since the objects are not available from the top-level module anymore at runtime.

I would like Ruff to check if an object is added to the module's __all__ list before moving it under TYPE_CHECKING.

This __all__ variable is a sequence of strings, tuple or list, and can unfortunately be constructed dynamically, so this complicates things: __all__ = ["A", *other_list] + list(some_tuple). If supporting dynamically constructed lists is too hard, for a first version Ruff could only support statically defined lists/tuples.

In the meantime, and as explained above, I can simply stop importing future annotations, and Ruff will not refactor anything.

@charliermarsh
Copy link
Member

I believe this is fixed on main and will be out in a new release shortly.

@pawamoy
Copy link
Author

pawamoy commented Aug 1, 2023

Incredible, thank you so much!

@charliermarsh
Copy link
Member

This should be fixed in v0.0.282, which is out now.

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

No branches or pull requests

2 participants