You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Intellisense doesn't respect __all__ when using import * #494
We won't be changing this because (1) there are legitimate reasons to want to ignore __all__ and (2) use of import * outside of the REPL is generally discouraged in Python.
I agree that it is generally discouraged but in certain situations it makes sense, for example within a library to expose members of internal modules within a single public facing module. Instead of explicitly importing each name of the internal modules, a star import is quite handy and it also serves for clearly defining what the public API is made out of.
Apart from this, if someone trusts the intellisense and an __all__ is in play like in my example above, then the code will fail at runtime. I thought this should be a good reason to have a red squiggly line.
Squiggle underlines gets into linting which means we rely on Pylint, flake8, or whatever linter you choose to use. So if you want to be warned that you are using something not contained in __all__ then that falls under the purview of your chosen linter.
I'm not sure if we're on the same page here. Ignore the squiggle lines for now. The main problem is that intellisense displays a lot more than what is actually possible to invoke. The members just do not exist and there will be a hard error at runtime. This is not about warnings or hiding private functions from novice users, it's about correctly computing the set of reachable symbols. Have a look at the example again to see what I mean.
If this is still something not going to be fixed (IMO it's a bug since intellisense in that case let's you construct invalid code), would you accept a PR for it?
OK, now I see where you're coming from with your example. Sorry about the misunderstanding. 😄 I've re-opened this as an issue and I have confirmed this issue does exist.
Activity
brettcannon commentedon Jan 2, 2018
We won't be changing this because (1) there are legitimate reasons to want to ignore
__all__and (2) use ofimport *outside of the REPL is generally discouraged in Python.letmaik commentedon Jan 3, 2018
I agree that it is generally discouraged but in certain situations it makes sense, for example within a library to expose members of internal modules within a single public facing module. Instead of explicitly importing each name of the internal modules, a star import is quite handy and it also serves for clearly defining what the public API is made out of.
Apart from this, if someone trusts the intellisense and an
__all__is in play like in my example above, then the code will fail at runtime. I thought this should be a good reason to have a red squiggly line.brettcannon commentedon Jan 3, 2018
Squiggle underlines gets into linting which means we rely on Pylint, flake8, or whatever linter you choose to use. So if you want to be warned that you are using something not contained in
__all__then that falls under the purview of your chosen linter.letmaik commentedon Jan 8, 2018
I'm not sure if we're on the same page here. Ignore the squiggle lines for now. The main problem is that intellisense displays a lot more than what is actually possible to invoke. The members just do not exist and there will be a hard error at runtime. This is not about warnings or hiding private functions from novice users, it's about correctly computing the set of reachable symbols. Have a look at the example again to see what I mean.
If this is still something not going to be fixed (IMO it's a bug since intellisense in that case let's you construct invalid code), would you accept a PR for it?
brettcannon commentedon Jan 8, 2018
OK, now I see where you're coming from with your example. Sorry about the misunderstanding. 😄 I've re-opened this as an issue and I have confirmed this issue does exist.
8 remaining items
munael commentedon Jan 25, 2019
Still an issue in the Microsoft Python Language Server.
Python extension: 2018.12.1 (with the early/nightly updates setting set)
VS Code: 1.31.0 (Insiders)
Is there a more lively issue tracking this?
brettcannon commentedon Feb 15, 2019
I can verify this isn't working in the language server v0.1.78.
I've opened microsoft/python-language-server#619 to track this upstream.
luabud commentedon Sep 11, 2019
Fixed upstream.