That is a Pylance error.

You can create a pyrightconfig.json file at the root of your workspace and define the files to be exclude-d from analysis or completely ignore-d:

{
    "ignore": [
        "**/*.ipynb",
    ],
}

You can even list up specific filenames:

{
    "ignore": [
        "notimportant.ipynb",
        "test.ipynb",
    ],
}

Historical Notes:

It initially didn't work for Jupyter Notebooks (.ipynb):
https://github.com/microsoft/pylance-release/issues/2135

This happens because pyright doesn't see the file as a "*.ipynb". The file is being preprocessed (to combine all of the cells) in the notebook by the VS Code Python extension, and the resulting combined file is then passed to pyright for analysis.

The pylance team is actively working on changing the way this works. I'm going to transfer this bug to the pylance-release repo so it gets the attention it deserves.

That Github issue has since been resolved the fix was deployed as part of pylance 2022.8.51: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#2022851-31-august-2022-prerelease

Notable changes:

• ...
• Bug Fix: Ignoring *.ipynb files does not work (pylance-release#2135)

If it somehow still does not work, check the version of pylance on your VS Code.

1. Find the error-message you want to modify/disable in the Pylance's Diagnostic Severity Rules (in my case "reportMissingImports")
2. Modify settings.json with "reportMissingImports": "none" (see diagnosis reporting levels in Pylance's Settings and Customization)

The entire JSON-code to be inserted into the settings.json is:

"python.analysis.diagnosticSeverityOverrides": {
    "reportMissingImports": "none"
}

As an aside, if you want to be at least informed about unused imports, you can use:

"python.analysis.diagnosticSeverityOverrides": {
    "reportUnusedImport": "information",
    "reportMissingImports": "none"
}

PS: regarding the settings.json - location

Along with the global settings.json there are also local versions in your VS-Code-projects' parent directories. In the following, example paths are provided based on my Windows 10 - OS:

• global: C:\Users\user.name\AppData\Roaming\Code\User\settings.json
• local: .vscode/settings.json

These local project settings override the global ones, if desired.

insert this:

# type: ignore

paste it at the top of the file to ignore the file

paste it at the end of a line to ignore the line

Reference: https://www.reddit.com/r/VisualStudioCode/comments/i3mpct/comment/g5bkx9u/

Please see: https://github.com/microsoft/pyright/blob/main/docs/configuration.md

I you want to disable everything (I assume all output from pylance are warnings),

you can add a <project-root>/pyrightconfig.json in your repo:

{
    "ignore": [
        "**"
    ]
}

Please read the link above for all the options and some samples at the end.

You can also add a commented line/lines in each specific file, This is nice when you explore and try to fix errors.

# <inside your python file that show this errors>
# pyright: reportUndefinedVariable=false, reportMissingImports=false, 
# pyright: reportOptionalSubscript=false, reportInvalidStringEscapeSequence=false

You can add the following settings in settings.json configuration file:

"python.analysis.diagnosticSeverityOverrides": {
    "reportUndefinedVariable": "none"
}

Or you can search for python.analysis.diagnosticSeverityOverrides in the settings, click Add Item button to select "reportUndefinedVariable", "none":

Result:

By default, pyright (the type checker upon which pylance is built) does not report the use of Unknown types. It does this only if you've enabled "strict mode". These strict-mode checks are designed for people who want to know about any potential "holes" in their type checking. If you're importing types from libraries that have incomplete types, you will naturally have holes in your type checking, so using these strict mode checks doesn't make sense in this case. Your options are: 1) disable the reportUnknown... family of diagnostic checks (you can manually enable other strict-mode checks if you'd like), or 2) augment the type information for the libraries you're consuming via type stubs so the type information is complete.