Wildcard imports trip up module discovery? `not a known attribute of module`

[ewerybody]

Type: Bug

Hello Pylance crew! I know "Wildcard imports ... should be avoided" but we use them in some selected places for constants and common stuff.

Found

I'm experiencing some problems finding explicitly imported modules and their functions using wildcard imports.

So, I'm basically:

• importing a module.submodule1
• do a wildcard import (from a file also importing module.submodule2)
• try to use module.submodule1
• Pylance(reportAttributeAccessIssue)

  "submodule1" is not a known attribute of module "module"

  • cannot goto definition in submodule1
  • cannot goto definition of submodule1 (is that a separate issue?)

goto submodule function definition and hover popup works right away as soon as the wildcard import is commented out or import module.submodule2 is removed from the wildcard imported file, or when I explicitly define __all__.

Expected

The module should be found as it is in the live code or when stepping through with the debugger (Or when the * import is commented out), (Or when __all__ is set up in the wildcard imported module) Or there should be some information on the Pylance error on WHY this is the case like "wildcard imports make it impossible to guess how members of module are mangled. Use __all__ declaration."? 🤷‍♀️

Repro

I was able to cook it down to this setup:

• __init__.py - root script importing mylib.a and * from my_common_stuffs
• my_common_stuffs.py - importing mylib.b
• mylib
  • __init__.py - can be empty
  • a.py - defining some function
  • b.py - can be empty

Where the code in my_common_stuffs.py is as simple as:

import mylib.b
BLA = '123'

and in the root file it's like:

import mylib.a

from my_common_stuffs import *

mylib.a.do_something(BLA)

Extra

So while cooking the report I found that I should probably make use of __all__ :) But still it seems broken with this simple setup especially as it's actually running fine at runtime and debug!

Info

Extension version: 2024.9.100 (pre-release) VS Code version: Code 1.93.1 (38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40, 2024-09-11T17:20:05.685Z) OS version: Windows_NT x64 10.0.19045 Python Debugger: 2024.11.2024082901 (pre-release) Modes:

A/B Experiments

``` vsliv368:30146709 vspor879:30202332 vspor708:30202333 vspor363:30204092 vscod805:30301674 binariesv615:30325510 vsaa593:30376534 py29gd2263:31024239 vscaat:30438848 c4g48928:30535728 azure-dev_surveyonecf:30548226 962ge761:30959799 pythongtdpath:30769146 welcomedialog:30910333 pythonnoceb:30805159 asynctok:30898717 pythonmypyd1:30879173 h48ei257:31000450 pythontbext0:30879054 accentitlementsc:30995553 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 cppperfnew:31000557 dsvsc020:30976470 pythonait:31006305 dsvsc021:30996838 724cj586:31013169 a69g1124:31058053 dvdeprecation:31068756 dwnewjupytercf:31046870 newcmakeconfigv2:31071590 impr_priority:31102340 refactort:31108082 pythonrstrctxt:31112756 flightc:31134773 wkspc-onlycs-t:31132770 wkspc-ranged-t:31125599 autoexpandse:31133494 ei213698:31121563 iacca1:31138162 ```

[danilociaffi]

Same here. Moreover this happens with wildcard imports in libraries (I can't do anything about that), for example:

where django.contrib.gis.forms contains:

from django.forms import *  # NOQA
...

[KacieKK]

Thanks for reporting this issue, I can repro it as well.

[heejaechang]

so, the bug is from my_common_stuffs import * removing a from myLib for the file when my_common_stuffs contains import myLib.xx without __all__.

and that is different than from django.forms import * # NOQA not exporting CharField

that's because pyi for geoforms doesn't have from django.forms import *. for that one, we either need to update django-stubs (if it is public api), or you could delete our bundled django-stubs from ...\.vscode\extensions\ms-python.vscode-pylance-2024.9.101\dist\bundled\stubs\django-stubs