The Python section of the VS Code marketplace is crowded. Search for "Python" and you get hundreds of results, a good number of them untouched since 2021, and several that duplicate features the editor already ships. The list worth your time is far shorter. Below are ten extensions that hold up in real projects, with the annoying parts left in, plus an order to install them so your editor stays fast.

The foundation: Python and Pylance

Python (Microsoft)

Install this first. It brings the debugger, the test runner, environment switching, and Pylance along with it. The one command you need on day one is Python: Select Interpreter from the command palette; picking the right virtual environment fixes the majority of "IntelliSense is broken" complaints.

Useful when: every project, without exception.
Watch out for: monorepos with several virtual environments. The extension occasionally grabs the wrong one, and the fix is re-selecting the interpreter rather than reinstalling anything.

Pylance

Pylance is the language server that makes go-to-definition, rename, and quick fixes feel instant. Its type inference is good enough that you get value from type hints without running mypy on every save. You can set the checking level per project with python.analysis.typeCheckingMode: keep application code on basic and libraries on strict.

Watch out for: strict mode on a legacy codebase. Turning it on across 40,000 lines produces more red than anyone will fix. Enable it folder by folder instead.

Linting and formatting, settled in one file

Ruff

Ruff covers most of what flake8, isort, pyupgrade, and a chunk of bandit used to do, and it runs fast enough that linting on save stops being a decision. Keep the rules in your project file so teammates and CI agree:

[tool.ruff]
line-length = 100

[tool.ruff.lint]
select = ["E", "F", "I", "UP", "B", "SIM"]

Watch out for: custom flake8 plugins. If your team wrote internal lint rules, Ruff cannot load them; you either port the rule or keep flake8 running alongside.

Black Formatter

Format on save, no debates. Black's value is that it removes style discussion from code review entirely. If you already run Ruff, ruff format produces nearly identical output in the same tool, which is one less extension to manage. Black stays worthwhile if your team has standardized on it.

Watch out for: the opinionated line wrapping. Teams used to 79-character lines and manual hanging indents will see large diffs in the first week.

Even Better TOML

Modern Python projects are configured in pyproject.toml, and this extension validates it against the right schema. It catches typos like [tool.ruff.lints] before you spend twenty minutes wondering why a rule is not applying.

Catch mistakes before you run anything

Error Lens

Error Lens prints diagnostics at the end of the offending line, so unused imports and undefined names are visible while you type instead of after a save.

Watch out for: visual noise. On a file with dozens of warnings it becomes unreadable. Set errorLens.severity to error, or turn it off for Markdown and JSON files.

Python Debugger

Breakpoints, conditional breakpoints, logpoints, and watch expressions, driven by debugpy. The conditional breakpoint alone saves an afternoon when a loop fails on iteration 900 out of 10,000. Commit a launch.json with a config for your test runner so nobody has to build one.

Watch out for: subprocesses and remote containers. Attaching takes a little configuration, and it is the one part of debugging people give up on too early.

Notebooks and data work

Jupyter

Runs .ipynb files inside the editor with a kernel picker and a variable explorer. The underrated part is the interactive window: put # %% before a block in a plain .py file and run it cell by cell. You get exploration without a notebook in your repository.

Watch out for: notebooks with thousands of saved outputs. They get slow to open and painful to diff. Clear outputs before committing.

Data Wrangler

Opens a pandas DataFrame in a grid with column statistics, then generates the cleaning code for what you did. Useful for first contact with an unfamiliar dataset.

Watch out for: it assumes pandas and loads the data a second time. For a small CSV, a few lines in the terminal are quicker.

Project and team hygiene

Dev Containers

Describe the environment in .devcontainer/devcontainer.json, and VS Code runs your whole setup inside it, extensions included. This is the cleanest answer to "it works on my machine" for teams with conflicting system dependencies.

Watch out for: it requires Docker fluency, the first build is slow, and filesystem performance on some host systems needs tuning.

GitLens

Inline blame and file history answer "why is this line like this" without leaving the editor. The compare-revisions view is genuinely good for reviewing your own branch before opening a pull request.

Watch out for: gutter clutter. Some hosted features ask you to sign in; the local history tools do not. If you only want blame, disable the rest.

Documentation you will actually keep

autoDocstring

Type three quotes under a function and it generates a docstring skeleton from the signature in Google, NumPy, or Sphinx style. It removes the tedium of formatting, which is usually the real reason docstrings get skipped.

Watch out for: placeholder text you never replace. Use the generated skeleton for arguments and return values, then write the two sentences explaining why the function exists. That part does not generate itself.

A setup order that works

1. Install Python and Pylance, then select the interpreter for the project before touching anything else.
2. Add Ruff and put one config in pyproject.toml. Decide now whether ruff format replaces Black.
3. Add Error Lens if you want inline feedback, then lower its severity until it stops shouting.
4. Add Python Debugger and commit a launch.json with at least one working config for your test runner.
5. Add project-specific tools last: Jupyter and Data Wrangler for data work, Dev Containers for complicated environments, GitLens if you spend real time in history.

Keep a .vscode/extensions.json with recommendations so new teammates get a prompt instead of a setup document. If you work across stacks, use VS Code profiles to keep a data profile and a web profile separate, so neither loads the other's extensions. And before installing anything that executes code on your machine, check the publisher and how actively the extension is maintained.

The best measure of this list is subtraction. If an extension duplicates something the editor already does, it costs startup time and adds a setting you will forget you changed. Install the five that matter for your work, and add the rest the day you actually miss them.

Photo: Nemuel Sereti / Pexels