What is a Python language server?

by Tim Hopper

Type a dot after a variable in your editor and a list of methods appears. Hover a function and its signature shows up in a tooltip. Right-click an import and “Go to definition” jumps to the source. Most Python developers have used these features for years without knowing the name of the program behind them.

That program is a language server. It is a separate process running alongside your editor, and it is doing most of the work readers usually credit to “the editor.” Naming it explains why VS Code, Neovim, Cursor, and Zed give you the same autocomplete on the same file, and why a faster type checker makes your editor feel faster.

What a language server actually is

A language server is a long-running process that analyzes source code and answers questions about it. Your editor is the client; the language server is the backend. The two communicate over the Language Server Protocol (LSP), a JSON-RPC standard Microsoft published in 2016 to break the N-by-M problem of editors versus languages.

Before LSP, every editor had to ship its own implementation of every language feature. Adding Python autocomplete to a new editor meant writing it from scratch. LSP changed the math: the language community ships one server, and any LSP-compatible editor can talk to it. That is why ty’s autocomplete works in VS Code, Neovim, Zed, and PyCharm with no per-editor port. The work happens in the server.

A Python language server typically runs in the background while you edit. It parses the file you have open, builds an internal model of the code (an AST, a symbol table, sometimes a full type-inferred view), and updates that model as you type. The editor sends events (“the user just typed requests.”) and the server replies with structured answers (“here are 47 attributes of the requests module, ranked, with docstrings”).

What a Python language server gives you

The features split into two buckets.

Navigation and editing features work on syntax and symbol tables:

Code completion (the dropdown after a .)
Hover information (signatures, docstrings, inferred types)
Go-to-definition, go-to-declaration, and go-to-type-definition
Find-all-references
Rename refactoring (the cross-file kind that updates every call site)
Signature help inside a function call
Document and workspace symbol search
Inlay hints (the gray inferred types that appear next to variables)

Diagnostics are the squiggles you see in the editor:

Type errors from a static type checker
Lint warnings from a code-quality tool
Unused imports, undefined names, and similar pyflakes-style checks
Format-on-save and quick-fix actions

One server does not have to provide both buckets. Many Python language servers wrap an external analyzer for the diagnostics half: python-lsp-server calls into pyflakes, pycodestyle, and others through plugins. Newer Rust-based servers like ty and Pyrefly integrate the type checker and the language server in the same binary, which is why their navigation and diagnostics stay in sync as you type.

Map the current Python language servers

Server	Backed by	License	What it gives you
Pylance	Microsoft	Proprietary, VS Code only	The default VS Code experience; built on pyright with closed-source extras
pyright	Microsoft	MIT	Open-source CLI and language server; the engine inside Pylance
Basedpyright	Community fork	MIT	Pylance-style features in any LSP editor; ships on PyPI
ty	Astral	MIT	Type checker and full LSP in one Rust binary; gradual typing
Pyrefly	Meta	MIT	Aggressive inference; runs on Instagram’s 20M-line codebase
Zuban	David Halter	AGPL-3.0 + commercial	Mypy-compatible mode; written by the author of Jedi
python-lsp-server (pylsp)	Spyder IDE team + community	MIT	Plugin host that wraps Jedi, pyflakes, pycodestyle, Ruff, and more
Jedi Language Server	Samuel Roeca	MIT	LSP wrapper around the Jedi autocompletion library; in maintenance mode
`ruff server`	Astral	MIT	Lint and format diagnostics only; ships inside the Ruff binary

Pylance is the default in VS Code and Cursor’s official builds, and it is the one most readers have used without knowing. The license restricts it to Microsoft VS Code and a small number of approved forks, which is why VSCodium, Positron, and other VS Code derivatives ship Basedpyright or pyright instead. Pylance is free to use but not open source.

Ruff is in a category of its own. ruff server (built into Ruff since 0.5.3, replacing the earlier ruff-lsp shim) only provides lint and format diagnostics. It is meant to run alongside a type-checking language server, not replace one. Most Python setups run two servers at once: one for types and one for lint and format.

Jedi Language Server is the historical fallback for editors that needed something lightweight and pure-Python. Its own README now recommends Zuban as a successor, which signals where the legacy branch is heading. Jedi the autocompletion library remains widely used inside other tools (including pylsp).

Why language servers and type checkers overlap

The line between “type checker” and “language server” is mostly a packaging decision. Six of the nine entries in the table above (pyright, Basedpyright, ty, Pyrefly, Zuban, plus Pylance, which wraps pyright) are full type checkers as well as language servers. They had to build a type-inferred model of your code to give you accurate autocomplete; once they had that model, exposing it as a CLI type checker took little extra work.

The shapes the field has settled into are roughly: type checkers that ship an LSP mode (pyright, ty, Pyrefly, and Zuban are primarily type checkers, with the language server exposed by a --langserver or server flag on the same binary); language servers that wrap an external checker (python-lsp-server hands off to plugins, Pylance bundles pyright with proprietary editor features on top); and language servers that do not aim to type-check at all (Jedi Language Server provides navigation through Jedi’s runtime-style inference, ruff server provides lint diagnostics).

mypy is the conspicuous absentee. It does not ship a language server. Teams that use mypy in CI typically pair it with pyright, Basedpyright, or ty in the editor for the live feedback half. The two halves can disagree: mypy might pass while pyright complains, because they have different defaults for unannotated code (see How do Python type checkers compare?).

The practical implication is that your editor’s “Python intelligence” is usually two or three programs working together. A typical 2026 setup pairs a type-checking language server (pyright, Basedpyright, or ty) for navigation and type squiggles with ruff server for lint and format squiggles. Teams often add mypy on the command line in CI. The editor talks LSP to all of them.

Pick a server for your editor

For nuance on the type-checker side, see How do Python type checkers compare?.

If you use Microsoft VS Code or Cursor and want the default to work, leave Pylance on. Add ruff server for lint and format.
If you use a VS Code fork (VSCodium, Positron) or want an open-source stack, Basedpyright is the closest to Pylance feature-for-feature without the license restriction. Add ruff server.
If you are betting on a newer type checker, use that project’s bundled language server: ty’s VS Code extension, Pyrefly’s, or Zuban’s. The CLI checker and the editor experience stay in sync.
If you use Neovim, Helix, Emacs, or another LSP-first editor, all of pyright, Basedpyright, ty, Pyrefly, and Zuban work via standard LSP clients. python-lsp-server is the option for aggregating multiple analyzers under a single plugin host.
If you want a minimal autocompletion-only setup with no type checking, Jedi Language Server still works and installs easily, though its maintainer now recommends Zuban for active development.

The choice matters less than it used to. The major Python language servers all ship LSP support, all read pyproject.toml, and all give you completion, hover, and go-to-definition out of the box. Where they differ (speed, conformance to the typing spec, treatment of unannotated code, license) is the same place the underlying type checkers differ.

Learn More

Last updated on May 3, 2026

What is a Python Interpreter?What is a Python module?

Please submit corrections and feedback...