Don't show errors in stdlib files

[mjbvz]

1. Turn on analysis
2. Run go to definition on join from os.path

Bug My problem count explodes:

I wouldn't expect analysis to kick in for files from the standard library like this

[rchiodo]

I would hazard a guess that you have a pyproject.toml or a pyrightconfig.json? The errors are likely a result of this: https://github.com/microsoft/pylance-release/wiki/Settings.json-overridden-by-Pyrightconfig.json-or-Pyproject.toml

It's forcing your typecheckingmode to default to 'basic'

[mjbvz]

I'm pretty sure I just turned on type checking from the language status menu. I don't see those files in my project

[rchiodo]

That's expected behavior then. typeCheckingMode applies to all open files, regardless of if they're under a workspace folder or not.

What you're asking for is typechecking only on 1st party source and not 3rd party source it seems like? Seems reasonable to me. Why would anybody care to type check code that isn't their own?

[rchiodo]

One way to workaround this is to add a glob to the 'ignore' setting:

"python.analysis.ignore": ["${workspaceFolder}/venv/**/*"]

[rchiodo]

Maybe we should add all of the site-packages folders to the default ignore list?

[heejaechang]

we show errors from any file opened in vscode. if your go to def opened a file, we will show errors on that file as long as it stays as open. once you close that file, they will go away. and that behavior is by design to support orphan files opened in editor along with folder

you could request enhancement request though. and we see how many upvote we get.

[mjbvz]

Feels like this scenario is common enough that ignoring the standard library would be a reasonable default. When would you want these errors to show up?

[heejaechang]

standard library typeshed authors? it would be nice to have a way to categorize problems in UI. so less important errors can group differently than other more important errors.

[mjbvz]

standard library typeshed authors?

Having an option (with no errors reported by default) seems reasonable for the majority of users

[heejaechang]

we could add an option for it, but usually user doesn't leave stdlib file open for long time? they usually either open it to see some definition/signature and close it. what is the scenario where you leave them open for long time?

[mjbvz]

Yes that's exactly the problem I ran into:

1. Run go to def on stdlib symbol to quickly browse the code
2. File opens and I am flooded with 100+ errors
3. The errors do go away after I close the file but it's distracting to suddenly have that many errors appear and also distracting to see all the red lines highlighted in the stdlib file

[Ravencentric]

I would love to see everything in stdlib/venv get excluded. It's just pointless distraction.

[garymm]

I'm struggling to configure VS Code to ignore the errors from the stdlib.

I have this in settings.json:

"python.analysis.ignore": [
    "${workspaceFolder}/.venv",
    "**/python3.*"
],

The errors are showing up in files with paths like: /opt/homebrew/Cellar/[email protected]/3.11.9_1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/typing.py

(.venv/bin/python is a symlink to /opt/homebrew/Cellar/[email protected]/3.11.9_1/Frameworks/Python.framework/Versions/3.11/bin/python3.11)

I'd like to not hard-code python3.11 or homebrew in the settings, ideally.

Any tips?