Pylance: Python language server for VS Code, its analysis modes, and what stays proprietary

A documentation repository for a non-open-source extension

This repository is the issue tracker and documentation home for Pylance, the Python language server extension for Visual Studio Code. The Pylance source code is not here and is not published anywhere else. The repository's license is CC-BY-4.0, which covers the documentation content rather than any Pylance code: files such as MIGRATING_TO_PYLANCE.md, USING_WITH_PYRIGHT.md, FAQ.md, TROUBLESHOOTING.md, DIAGNOSTIC_SEVERITY_RULES.md, and MOST_REQUESTED_FEATURES_AND_BUGS.md.

For engineers who want to contribute to the type-checking behavior itself, the path goes to Pyright, the open-source project at github.com/microsoft/pyright. Pyright is the engine that powers Pylance's type inference, and changes accepted into Pyright eventually reach Pylance. Filing an issue in this repository is the only direct channel to the Pylance team for bugs, feature requests, or questions about behavior specific to the VS Code extension.

The name itself is a small reference to Lancelot, the first knight to answer the bridgekeeper's questions in Monty Python and the Holy Grail.

Pylance arrives through the Python extension, not a direct download

Pylance does not have a pip package or a standalone installer. It ships as an optional dependency of the Python extension for Visual Studio Code, and installing the Python extension from the VS Code marketplace pulls Pylance in at the same time. Opening a Python (.py) file then triggers activation automatically. No separate download, no command-line step, and no manual configuration is needed for the default setup.

If VS Code was previously configured to use a different language server, one manual change is required. The setting goes in settings.json, where the README accepts either `"Default"` or `"Pylance"` as a valid value:

"python.languageServer": "Default"

Setting the value to `"Default"` lets VS Code choose, which at present resolves to Pylance. Without this change, a workspace that previously pinned a different language server will not automatically switch. The Settings Editor UI in VS Code can make the same adjustment without editing settings.json directly.

How python.analysis.languageServerMode and its three modes set the feature ceiling

The `python.analysis.languageServerMode` setting controls which IntelliSense features are active by setting a collection of defaults for other settings underneath. Three values are available: `light`, `default`, and `full`. The setting's default value is `default`.

Moving from `default` to `full` adds several features that are off in the default configuration. In `default` mode, `python.analysis.autoImportCompletions` is false, meaning Pylance does not add auto-import completions for modules not yet present in the file. Full mode sets it to true. Similarly, `python.analysis.functionReturnTypes`, which infers and displays return types for functions, is false in both `light` and `default` and only becomes true in `full`. The `python.analysis.userFileIndexingLimit` setting is 2000 in `default` mode and -1, meaning no limit, in `full` mode. On a project with more than 2000 Python files, that difference determines whether all files get indexed.

In `full` mode, `python.analysis.nodeExecutable` is set to `"auto"`, while in `light` and `default` it is an empty string. Individual settings can override whatever a mode defaults to, which the README states explicitly, so setting `python.analysis.languageServerMode` to `light` does not prevent you from re-enabling specific features by setting them individually in settings.json.

Light mode sets python.analysis.exclude to all files, which blocks analysis by default

The behavior of `light` mode deserves closer attention than its description gives. The README calls it designed for users seeking a lightweight, memory-efficient setup and says it makes Pylance function more like a streamlined text editor. What the description does not state is shown in the settings table: `python.analysis.exclude` is set to `["**"]` in `light` mode.

A value of `["**"]` for the exclude setting matches every file in the workspace. Combined with `python.analysis.indexing` set to false and `python.analysis.useLibraryCodeForTypes` set to false, `light` mode does not merely reduce the scope of analysis. It stops file analysis entirely by excluding every workspace file before analysis begins. Completions derived from the user's own codebase, diagnostics for code in the current project, and IntelliSense drawn from project-specific types all depend on Pylance reading those files. With `python.analysis.exclude` set to `["**"]`, none of that runs unless you override the setting yourself.

A developer who switches to `light` mode to reduce editor slowness will get no project-specific completions or diagnostics, not because those features are absent from Pylance but because the exclude pattern prevents the extension from reading the workspace files. The README's description of the mode never states this consequence plainly, leaving the practical outcome implicit in the settings table.

Type checking defaults to off, and pyrightconfig.json can override settings.json silently

Type checking analysis in Pylance is off unless you turn it on. The setting is `python.analysis.typeCheckingMode`, and its default value is off. Four values are available: off, basic, standard, and strict. Each level in this hierarchy accumulates all the rules from the levels below it and adds its own on top of those. The off level still produces diagnostics for unresolved imports and variables; it only disables the type checking analysis specifically.

For the complete list of rules that each level enables, the README points to Pyright's documentation at microsoft.github.io/pyright. Pylance does not independently document those rules in this repository.

One point the README flags explicitly: the value of `python.analysis.typeCheckingMode` can be overridden by a `pyrightconfig.json` or a `pyproject.toml` file present in the workspace. Either of those files takes precedence over settings.json. That matters in a monorepo where a pyrightconfig.json lives at the project root with its own typeCheckingMode entry. Nothing in the editor signals that the config file has taken over; settings.json still shows the mode while pyrightconfig.json or pyproject.toml takes precedence silently. The README points to further reading on that interaction at aka.ms/AArua4c.

Setting typeCheckingMode to off improves performance in large codebases, according to the README, because type checking analysis is resource-intensive at that scale.

The Install Matching Type Stubs command and the Copilot Chat skill set

Two VS Code commands ship with Pylance beyond the standard language server features. The first, `Pylance: Install Matching Type Stubs`, searches for and installs type stub packages for dependencies already present in the active Python environment. Type stubs are separate packages that carry type annotations for libraries that do not bundle them natively. Without stubs, Pylance infers types from the installed library's source code, which can be incomplete or entirely absent for some packages. The command automates the step of identifying the right stub package and installing it.

The second command is `Pylance: Toggle Block Comment`, which toggles block commenting on selected Python code. Both commands appear in the VS Code command palette.

Copilot Chat skills are also part of Pylance's documented feature set. These cover fact-grounded Python help, type inference, inline type annotations, stub authoring, Pylance documentation, refactoring, profiling, and adding or dropping Python version support. The README does not document how these skills differ from GitHub Copilot's general coding assistance or what triggers each one. Using them requires GitHub Copilot to be active in VS Code; no further detail on the integration appears in this repository.

Individual settings override the defaults that languageServerMode puts in place

When an IntelliSense feature does not behave as expected, the first place to check is which settings are currently active, because `python.analysis.languageServerMode` sets defaults that individual settings can override in either direction. A mode of `light` sets `python.analysis.autoImportCompletions` to false, but setting `python.analysis.autoImportCompletions` to true in settings.json restores the feature without changing the mode. A mode of `default` leaves `python.analysis.functionReturnTypes` off, but that setting can also be turned on independently without switching to `full`.

The repository top level includes DIAGNOSTIC_SEVERITY_RULES.md, FAQ.md, and TROUBLESHOOTING.md. None of those documents' content is reproduced in the README, so they are the next stop when a diagnostic is unexpected or a feature is missing. Issues about the extension's behavior, not about Pyright itself, go to the issue tracker in this repository, while issues about type-checking logic and inference rules belong in the Pyright repository at github.com/microsoft/pyright. The last push to this repository was on 2026-09-25, and the three most recent releases are 2026.4.1, 2026.3.105, and 2026.3.104.

Editorial conclusion

Pylance is the default Python language support in VS Code and activates without configuration once the Python extension is installed. Adopt it when your team uses VS Code and wants diagnostics and completions without a separate install step. Skip it when your organisation requires full source availability for every development tool, or when you need to modify the language server behavior beyond what settings expose. Before enabling type checking, check every workspace root for a pyrightconfig.json or pyproject.toml, because either overrides the typeCheckingMode you set in settings.json with no indicator in the editor.

Frequently asked questions

Official sources

1. Issues
2. License: CC-BY-4.0
3. microsoft/pylance-release on GitHub
4. README
5. Releases