Language server not recognising True or False as builtins

[jarshwah]

Environment data

• VS Code version: 1.28.2
• Extension version (available under the Extensions sidebar): 2018.10.0
• OS and version: OSX
• Python version (& distribution if applicable, e.g. Anaconda): python2.7 pyenv
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pyenv virtualenv

Language Server: Microsoft Python Language Server version 0.1.60.0 (from startup logs)

Actual behavior

False and True are now being marked as use before defined, suggesting they're no longer recognised as built ins.

Expected behavior

The poor booleans are not targeted as being issues.

Steps to reproduce:

See screenshot above.

[DonJayamanne]

Interesting, I cannot replicate this at my end.
Are you able to replicate this consistently?

[joelhock]

i have the same issue; even a simple test case like this triggers it:

if True:
    print "hi"

VS Code version: 1.28.2 and 1.29.0
Extension version (available under the Extensions sidebar): 2018.10.0
OS and version: OSX 10.14
Python version (& distribution if applicable, e.g. Anaconda): python 2.7.15 from homebrew
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Language Server: Microsoft Python Language Server version 0.1.60.0 (from startup logs)

[jakebailey]

I can make this happen on my machine, but only once, then it goes away for all files. I'll look into this upstream (and keep discussion there).

[DonJayamanne]

This issue was moved to microsoft/python-language-server#394

[jarshwah]

I can no longer replicate this issue within the same project for what it's worth.

[jakebailey]

I can't either, unfortunately. Making it very hard to track down...

[jarshwah]

Ok, I have been able to replicate this in my python 2.7 project.

When the project is first opened everything is fine. I notice that once the project has finished being analysed I see the underlining of True/False with use before def error.

I'm not sure if the warning is shown some time before analysis is completed though - as it takes about 10 minutes on my project and watching a single value for that long is tricky.

[mikew]

Same here:

[zbyszek-matuszewski]

I also see this problem.

VS Code version: 1.26.1
Extension version: 2018.10.1
OS and version: Ubuntu Linux 17.10, 64-bit
Python version: 2.7.14 and 3.6.6
Language Server: Microsoft Python Language Server version 0.1.60.0

[crucialfelix]

I have had it consistently for many weeks.

• VS Code Version 1.29.1 (1.29.1)
• Python (microsoft) extension 2018.10.1
• Python 2.7.10 64-bit
• Microsoft Python Language Server version 0.1.60.0
• OSX
• Python Extension Pack 1.4.0 (includes Magic Python syntax highlighting)

and ... just deactivated Python Extension Pack and the bug is gone. I think it was linter vs linter.

EDIT: I spoke too soon. I have disabled Python Extension Pack but the selected language mode still shows as "Magic Python"

pylint is currently not enabled and I'm getting a dialog advising me to activate it.

I still have many:

⚠️[Python] 'True' used before definition [use-before-def]

Visual Studio IntelliCode - Preview is on.
visualstudioexptteam.vscodeintellicode
Preview

No other python extensions enabled.

[bennettandrews]

• VS Code Version 1.29.1
• Python (ms-python.python) 2018.10.1
• Python 2.7.10 64-bit
• OSX

settings.json

{
    "python.linting.enabled": true,
    "python.linting.mypyEnabled": false,
    "python.linting.flake8Enabled": true,
    "python.linting.pylintEnabled": false,
}

[Evanlec]

I have this issue as well, amongst other random/erroneous things that Python linter reports as being used before definition. (tuple built-in type for example)

[jakebailey]

This is an upstream issue with the language server. If you have issues with True/False beign reported as use-before-def, we'd appreciate it if you could report it in microsoft/python-language-server#391, or create a new issue if it's detecting something other than True/False as use-before-def.

I've been attempting to reproduce this for the past few weeks without any luck, so if you can make it happen consistently in some setup, I'd appreciate knowing (again, in the other repo's issue tracker).

[brettcannon]

Fixed upstream.