Pylance-release: 'module' is not Accessed Pylance(Pylance is greyed out)

[pybash1]

When I am importing the python module 'requests'. PyLance or VSCode underlines it with yellow meaning warning. It is also shown in the problems panel in the integrated terminal of vscode. Hope it gets fixed soon. I did not use the Bug Report Template because I am not sure if it is a bug.

[pybash1]

Edit 1: While importing the module 'wget', the exact same thing happens. So does this mean that it happens with such type of web modules?

[erictraut]

This isn't a bug. The warning is telling you that the source code for this module can't be resolved within your configured Python environment. It is likely that either your configuration is wrong or the module isn't installed in that environment. If you don't care about this warning, you can disable it in the settings or configuration file.

[erictraut]

And the reason it's grayed out is because no other code in your source file is referring to requests.

[pybash1]

But how can you say that it is not installed in that environment when running the application and even using the module dosent give any error. And I meant that the word Pylance is greyed out. Not the module I know I didn't reffer to it. But I later I did and the code worked and ran fine. So could tell about that?

[pybash1]

I guess I should not ask this... But why did you transfer this issue?

[judej]

Pylance is greyed out because Pylance is the reporter of the error. With regard to the unresolved import warning, please take a look at the trouble shooting guide: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#unresolved-import-warnings

[pybash1]

Ok..that explains it. Thanks @judej

[pybash1]

By the way could you tell me what more info you need? I would be happy to help you... Because you added the waiting for info label...

[jakebailey]

Our issue template typically asks for logs; you may have selected the "question" which is more discussion based. I'd be interested in seeing some trace logs to see what paths are being used and what files are analyzed.

https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue mirrors the template instructions.

[pybash1]

Update -
After changing my interpreter from Python 3.7 to Anaconda Python 3.8.3 in VSCode

The issue was that I had python 3.7 selected in VSCode as my default interpreter but my os's default interpreter was conda 3.8.3 so all of my packages were installed there. But since Py 3.7 was selected in VSCode, Pylance thought it was not installed since it was installed for conda 3.8.3 and were not for py 3.7.

But due to some odd reason running it with 3.7 didn't give any error and was able to use the modules.

But I dont know why Pylance does this when I am importing a local file.

[pybash1]

@erictraut was actually correct in his 2nd comment

[jakebailey]

Your original issue was about requests, which isn't a local module (it'd be an installed package). You're now mentioning a local import, can you describe this setup at all? Are you assuming some sys.path modification that needs to be configured so we can find the import? https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#unresolved-import-warnings

[pybash1]

Ok, let me explain.

---

Terms used:
pip - pip3
Py, py - Python3
Conda, conda - Anaconda3

---

First I was trying to import requests, wget and some more modules. But it showed this error. Now few days back I just found out that inside VSCode my python interpreter was selected as Py3.7. But conda3.8.3 was my windows default interpreter. And thus all modules installed using pip were installed there. But PyLance tried to find in Py3.7 and they were not present. But the scripts never showed an error because when I was executing them through the terminal, they actually getting executed in Conda3.8.3. So when i changed my interpreter from py3.7 to conda3.8.3 in vscode all those errors were gone. And that fixed it.

---

But now if I try to import a local file, pylance shows the error. Executing it doesn't give any error. And workd fine. But Pylance Shows the error.

---

Hope this helps you. So could you fix so that importing local modules doesn't give an error. And also, PyLance says, this is a warning not an error. If you want I can attach a screenshot. Not using an virtual envirionment

---

A suggestion - could you make the warning underlines yellow instead of green, that would be better. Since, green kind of means there are no issue.

[pybash1]

Don't know why everything became a "h1"?

[jakebailey]

Pylance respects the interpreter chosen by the Python extension; if you have the wrong interpreter selected then we can't really do anything about that.

We want to show import resolution messages as they significantly impact the analysis. If you really don't care about import warnings, you can use diagnosticSeverityOverrides and silence them. This to me is a bad idea, as it means all of the info you're working with is silently wrong.

For local modules, your project layout may mean you need to set extraPaths: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#common-questions-and-issues

RE: h1, github issues are markdown, and putting ---- on the line after text makes it a header. I've edited your comment to make it readable again.

[pybash1]

Thanks for the edit... yeah i know the interpreter was my bad, sorry. But I don't know about the local modules. I can set extraPaths, but previously I never had to that. So I said. And the warnings are yellow, they are green because of my theme. And I used diagnosticSeverityOverrirdes and set it to information. that way it doesn't show a warning and I still get the info. Thanks. But could you make it so that I don't need to set extraPath for local modules.

[jakebailey]

The thing I'm curious about is "previously I never had to that"; previously meaning what? With a previous version of Pylance? With another language server setting? In another editor?

[pybash1]

The thing I'm curious about is "previously I never had to that"; previously meaning what? With a previous version of Pylance? With another language server setting? In another editor?

"previously I never had to do that" means with another language server. That is with the default Python extension from Microsoft.

[jakebailey]

I see. The previous default is Jedi, which has a pretty loose/forgiving import resolution system that favors resolving modules rather than erroring when they may not actually work at runtime. For local stuff, Pylance's behavior matches MPLS and other analyses that are more strict and try to inform of these issues. I don't know that we're likely to try and change that behavior, as we try to be as spec-compliant as possible (even if some projects require some extra configuration; most do not). The troubleshooting docs do describe this "import not resolved" message as much as possible for this reason.

What'd be most helpful is a description of your repo layout, in case it's something we can attempt to detect or handle through other means.

[pybash1]

What do you mean by repo layout? the file structure or hierarchy?

I don't know what the default one is? But I installed it from extension marketplace, named Python and author Microsoft.

[jakebailey]

The folder layout, and how the files import each other.

I'm talking the languageServer setting; Pylance is an option you had to configure to enable. If unset, that means jedi.

[pybash1]

Re: I didn't configure Pylance manually I just installed it from the extension store.

[pybash1]

The Folder Layout:
A lot to type, so attaching images.

Folder Layout:

Files and their Imports(the programs_start directory is not included because they do not import anything and are not part of the project):
main.py:

files.py:

windows.py:

web_search.py:

query_finder.py:

programs.py:

[limdauto]

FWIW I can confirm that I'm seeing the same thing. I have a function that is definitely being used. As you could see in the screenshot, Pylance does know that there are 10 references to this function but it's greyed out nonetheless.

[erictraut]

@limdauto, you're seeing a different issue unrelated to modules. A function whose name starts with an underscore is assumed to be private, and therefore intended only for use by callers within that module. You mentioned that there are 10 references to the function. Are they within the same module? If not, that explains why it is shown "grayed out". If your intent is to export it to other modules, you should change its name so it is not considered private.

[limdauto]

@erictraut Ah sorry! My bad! You are right: in my case this particular function needs to be changed to public because it's being used elsewhere. Thank you.

[pybash1]

any updates??

[jakebailey]

We are currently exploring ways in which we can improve our import resolution, or at least provide more guidance to fixing it. In your case, I did suggest extraPaths to mark extra import roots (which is our current suggestion) and we don't have any other guidance for when a project like this imports with unclear semantics (see also #253).

If there are updates, we'll put them here, but I'm fairly certain what you're seeing is a part of our current design and requires you to set extraPaths as is hinted in our troubleshooting docs.

[pybash1]

ok... and will this issue be closed, since it is kind of resolved??

[jakebailey]

If you mean that it's resolved now with extraPaths, then sure, we can close this issue.

[pybash1]

ok then, close it... thanks

[pybash1]

I just saw this today

from . import module doesn't give the error!

[jakebailey]

Yes, relative imports don't need paths to be able to resolve, as they know where they're relative to (the current module's folder). Using relative imports bypasses the problem.

I'm not sure why I didn't close this issue after you asked for it, oops. #68 and #253 largely supersede this issue, in any case.

[pybash1]

Alright, thanks!