Updated library guidance doc to clarify point of confusion about import forms.

This commit is contained in:
Eric Traut 2021-12-01 08:57:29 -08:00
parent 5ab4a01d1d
commit 7e59a19eaa

View File

@ -32,7 +32,7 @@ If a “py.typed” module is present, a type checker will treat all modules wit
Each module exposes a set of symbols. Some of these symbols are considered “private” — implementation details that are not part of the librarys interface. Type checkers like pyright use the following rules to determine which symbols are visible outside of the package.
* Symbols whose names begin with an underscore (but are not dunder names) are considered private.
* Imported symbols are considered private by default. If they use the “import A as A” (a redundant module alias), “from X import A as A” (a redundant symbol alias), or “from . import A” forms, symbol “A” is not private unless the name begins with an underscore. If a file `__init__.py` uses form “from .A import X”, symbol “A” is treated likewise. If a wildcard import (of the form “from X import *”) is used, all symbols referenced by the wildcard are not private.
* Imported symbols are considered private by default. If they use the “import A as A” (a redundant module alias), “from X import A as A” (a redundant symbol alias), or “from . import A” forms, symbol “A” is not private unless the name begins with an underscore. If a file `__init__.py` uses the form “from .A import X”, symbol “A” is not private unless the name begins with an underscore (but “X” is still private). If a wildcard import (of the form “from X import *”) is used, all symbols referenced by the wildcard are not private.
* A module can expose an `__all__` symbol at the module level that provides a list of names that are considered part of the interface. This overrides all other rules above, allowing imported symbols or symbols whose names begin with an underscore to be included in the interface.
* Local variables within a function (including nested functions) are always considered private.