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