Repository navigation
print, others flagged as "Undefined variable" (requests being handled before initialization is complete?) #1697
Description
Activity
Could you please provide the logs asked for in the template? I'd like to see the caching level you are using.
Hi Jake. Thanks for the response. I think you want me to follow:
So I did Python › Analysis: Log Level
Defines type of log messages language server writes into the output window.
TraceAnd Here's Output.Python:
User belongs to experiment group 'AlwaysDisplayTestExplorer - control' User belongs to experiment group 'ShowPlayIcon - start' User belongs to experiment group 'ShowExtensionSurveyPrompt - control' User belongs to experiment group 'AA_testing - experiment' > conda --version > pyenv root > python3.7 -c "import sys;print(sys.executable)" > python3.6 -c "import sys;print(sys.executable)" > python3 -c "import sys;print(sys.executable)" > python2 -c "import sys;print(sys.executable)" > python -c "import sys;print(sys.executable)" > py -3.7 -c "import sys;print(sys.executable)" > py -3.6 -c "import sys;print(sys.executable)" > py -3 -c "import sys;print(sys.executable)" > py -2 -c "import sys;print(sys.executable)" > python -c "import sys;print(sys.executable)" > conda info --json Starting Microsoft Python language server. > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\cygwin64\bin\python2.7.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\cygwin64\bin\python2.7.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python2.4.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python2.4.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > conda info --json > conda --versionI hope this is what you wanted.
Thanks again, Jake.
Love and peace,
JoeI just did a second run of my program just to be sure. Here's Output.python again.
User belongs to experiment group 'AlwaysDisplayTestExplorer - control' User belongs to experiment group 'ShowPlayIcon - start' User belongs to experiment group 'ShowExtensionSurveyPrompt - control' User belongs to experiment group 'AA_testing - experiment' > conda --version > pyenv root > python3.7 -c "import sys;print(sys.executable)" > python3.6 -c "import sys;print(sys.executable)" > python3 -c "import sys;print(sys.executable)" > python2 -c "import sys;print(sys.executable)" > python -c "import sys;print(sys.executable)" > py -3.7 -c "import sys;print(sys.executable)" > py -3.6 -c "import sys;print(sys.executable)" > py -3 -c "import sys;print(sys.executable)" > py -2 -c "import sys;print(sys.executable)" > python -c "import sys;print(sys.executable)" > conda info --json Starting Microsoft Python language server. > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\cygwin64\bin\python2.7.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\cygwin64\bin\python2.7.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python2.4.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Program Files (x86)\LilyPond\usr\bin\python2.4.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > C:\Python27\python.exe c:\Users\joeco\.vscode\extensions\ms-python.python-2019.10.41019\pythonFiles\interpreterInfo.py > conda info --json > conda --versionI see, you don't have trace logging enabled and I think you're in the wrong output tab. Add
"python.analysis.logLevel": "Trace"to your settings and reload, and your logs should be more verbose. You can find them in the "Python Language Server" part of the output panel (in the dropdown). See: https://github.com/microsoft/python-language-server/blob/master/TROUBLESHOOTING.md#filing-an-issueHi Jake. Thanks for your patience. I just
- set "python.analysis.logLevel": "Trace" in File>>Preferences>>Settings.
- restarted vscode which NOW comes up with Update 1.39.2!
- checked settings & still "python.analysis.logLevel" == Trace
I reopened the "offending" program == test_jsonschema.py & NOW print IS NOT FLAGGED as Undefined variable!
How time flies when you're having fun!
I just ran test_jsonschema.py
Now i open OUTPUT & select THE SECOND Python Language Server entry in the dropdown. N.B. the first had no output in the window.
Here is what the OUTPUT window says:
I am attaching the output as vscodePyLangServerLog.txt
Caching is disabled in those logs, so that's interesting.
Reloading fixing it doesn't surprise me, as the analysis will have been rerun.
I am having a similar issue with inbuilt functions and types such as
ValueErrorandfloat. I tried changing the settings as described above to Trace and this made theUndefined Variableerror go away.Changing the logging setting wouldn't have any effect. If you reloaded the editor when you changed the setting, the reload is what would have likely fixed it.
I'm having the same problem of "print" being marked as an undefined variable.
Trace output attached.
trace-logs.txtI can confirm this problem. I am having it for all built-ins (dict, len, print, list, ...) ?
python.analysis.cachingLevelis set toNoneto fix #1601 .Reacted by Michael AyeTo be clear, after disabling caching, did you restart the language server? I don't know if we currently handle the case of going from caching to no caching within the same run (the other way would work, though be less efficient).
Thanks. I did restart. Also, I find
[Info - 9:35:07 AM] Analysis caching mode: None.in the log file.BTW, analyzing in background is now very slow. It takes hours to finish and afterward, I am having the
Undefined variable ...problem.I'm having the same problem, but reloading resolves it. For now I have to reload every hour or so.
Reacted by Gui Talarico and Tom XuThis issue appears to affect many basic Python objects, like
str. Attaching screenshot.
Essentially this appears to be happening to anything that's declared in the global scope; things like
print,str, andlen, aren't "keywords" per se, but actual variables that exist in the scope and can be reassigned like any other variable, so we declare them in every module before analyzing. That's what appears to either not happen, or get lost along the way.Working on #1601 and #1414 may preclude this, since they affect the analysis order.
31 remaining items
No improvement for me. Builtins are still undefined and analyzing in background gets stuck. It seems that this only happens in big projects. I have no problems in smaller (less number of files) project.
Another possible reason is that cached generated stub for
builtinsis empty or damaged.pyi. This is unrelated to cachingNonesince that setting controls caching of analysis rather than stubs generated from the compiled modules. Chris Kuenneth (@kuelumbus) - try deleting everything in/home/chris/.cache/Microsoft/Python Language Server.However, I still see
Analysis of builtins (Builtins) on depth 0 completed in 365.12 ms.way at the end. This is the root, IMO.
Reacted by Nicolás Celedón CanalesNo change. I removed the cache and restarted Code. Right after the restart, the builtins were correctly flagged showing their correct doc strings. A cup of coffee later, the builtins are again flagged as undefined variable.
Could you try daily channel with 0.4.121? https://github.com/microsoft/python-language-server/wiki/Versioning-and-download-channels
Version 0.4.121 fixed it for me. However, I almost never see the doc string because it's constantly analyzing.
Now it's stuck in a reload loop. Note:
[Info - 3:59:15 PM] Workspace root: /home/chris/data/ml/Net [Info - 3:59:15 PM] GetCurrentSearchPaths /usr/bin/python3.7 [Info - 3:59:15 PM] Interpreter search paths: [Info - 3:59:15 PM] /usr/lib/python3.7 [Info - 3:59:15 PM] /usr/lib/python3.7/lib-dynload [Info - 3:59:15 PM] /home/chris/autocomplete [Info - 3:59:15 PM] /home/chris/.local/lib/python3.7/site-packages [Info - 3:59:15 PM] /data/chris/ml/Net [Info - 3:59:15 PM] /usr/local/lib/python3.7/dist-packages [Info - 3:59:15 PM] /usr/lib/python3/dist-packagesSomehow your workspace is a symlink to somewhere completely different outside of the workspace? What kind of setup do you have in your pythonpath? This seems very unusual.
Try setting
"python.analysis.watchSearchPaths": falseto disable file watching.There are no symlinks in the workspace but
/home/chris/datais a link to/data/chris. The workspace is accessible by/home/chris/data/ml/Netand/data/chris/ml/Net. Could this be the issue?Try setting
"python.analysis.watchSearchPaths": falseto disable file watching.resolved it. But also changing the workspace root to the direct path.
Thanks for your help.[Info - 8:12:55 PM] Workspace root: /data/chris/ml/Net [Info - 8:12:55 PM] GetCurrentSearchPaths /usr/bin/python3.7 [Info - 8:12:56 PM] Interpreter search paths: [Info - 8:12:56 PM] /usr/lib/python3.7 [Info - 8:12:56 PM] /usr/lib/python3.7/lib-dynload [Info - 8:12:56 PM] /home/chris/autocomplete [Info - 8:12:56 PM] /home/chris/.local/lib/python3.7/site-packages [Info - 8:12:56 PM] /usr/local/lib/python3.7/dist-packages [Info - 8:12:56 PM] /usr/lib/python3/dist-packagesOK, since reload is a different issue, I am going to close this one which is about builtins. Feel free to open new issue on reloads.
#1798as the symptom is that builtins are wrongly flagged as not defined, i don't see why this issue is being closed. the problem is still there, isn't it? That the underlying reason maybe (i don't know i'm not the developer) has nothing to do with built-ins isn't really the user's problem.
The builtins were being flagged as undefined as they hadn't been properly created, meaning users of the builtin wouldn't see that they exist and then show messages.
Indefinite reloads may or may not cause that issue (usually not, just infinite analysis), and IMO are not necessarily related. The infinite reload observed above was described as "the docstrings don't show up", not "things are shown as undefined"; if the analysis never completes it won't show linting messages. If it completes with bad state, then you'll get wrong messages, which is what the original issue described and should be fixed with the merged PR.
Reacted by Chris KuennethI can see that you mentioned
selfbeing marked as undefined; That sounds like another issue we would want a reproducer for.selfis not a part of the builtins code (which is what is fixed), but something different.If your issue persists, then we'd appreciate a new issue to take a look. (We prefer new issues that we can triage and merge, rather than lumping similar symptoms together in a single never-closed issue.)
selfissue is probably #1573
Environment data
Expected behaviour
print should NOT be flagged as "Undefined variable"
Actual behaviour
print is flagged as "Undefined variable"
Logs
Code Snippet / Additional lnformation