Fix imports in __init__.py files to explicitly re-export symbols #891
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements for Contributing to this repository
What does this PR do?
Fixes #842.
By default imports in
__init__.py
files are treated by type checkers (like mypy or pyright) as private.With this PR type checkers start to recognize selected symbols imported in
__init__.py
files as re-exported, so that code like this:is no longer treated as importing private implementation details of the library.
Description of the Change
In order to mark symbols as intended to be re-exported you can use one of the special import forms. This change does that by adding
from Y import X as X
(a redundant symbol alias) as described in official Import Conventions written by The Python Typing Team.Alternate Designs
As an alternative one might define the
__all__
module-level attribute in__init__.py
file that lists all the symbols intended to be re-exported. The symbols listed in__all__
are represented bystr
. Making sure that this is list up-to-date might become problematic as only type checkers use that information and not every IDE supports recognizing those strings as symbols, making it hard to maintain them.Possible Drawbacks
One have to remember to keep those re-export up-to-date to keep type checkers happy.
Verification Process
I've checked by running pyright on
if it gives a warning
reportPrivateImportUsage
.Additional Notes
Release Notes
Review checklist (to be filled by reviewers)
changelog/
label attached. If applicable it should have thebackward-incompatible
label attached.do-not-merge/
label attached.kind/
andseverity/
labels attached at least.