Pylance oder Ruff? Werkzeuge verstehen, richtig kombinieren

Black-kompatibel bedeutet: Ruff formatiert Python-Code nach exakt denselben Regeln wie das verbreitete Tool Black — konsequente Anführungszeichen, feste Zeilenlänge (88 Zeichen), kein Stil-Diskussionen. Ein Drop-in-Replacement: Wer bisher Black verwendet hat, kann ohne Anpassungen im Code vollständig zu Ruff wechseln.

---

TL;DR

Pylance ≠ Ruff. Beide zusammen = das stärkste Setup.

User Settings (%APPDATA%\Code\User\settings.json):

{
  "ruff.nativeServer": "on",
  "python.languageServer": "Pylance",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true
  }
}

Voraussetzung: Die VS-Code-Extension charliermarsh.ruff muss installiert sein. Erst dann greift editor.defaultFormatter = charliermarsh.ruff.

Empfehlung: Diesen Block trägst du in die VS-Code-User-Settings ein, also in %APPDATA%\Code\User\settings.json.

Workspace Settings (.vscode/settings.json im Projekt):

{
  "python.analysis.typeCheckingMode": "basic",
  "python.analysis.diagnosticMode": "openFilesOnly",
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python"
}

---

Was macht was? Zwei Werkzeuge — eine klare Trennung

Das häufigste Missverständnis: Ruff ersetzt Pylance nicht. Die beiden Tools lösen grundlegend verschiedene Probleme.

Funktion	Pylance	Ruff
IntelliSense / Autocomplete	✅	❌
Typ-Prüfung (via Pyright)	✅	❌
Go-to-Definition	✅	❌
Hover-Docs / Signaturen	✅	❌
Linting (flake8, pylint, …)	schwach	✅
Formatting (Black-kompatibel)	❌	✅
Import-Sortierung (isort)	❌	✅
Geschwindigkeit	normal	10–100× schneller

Pylance ist der Language Server — der Motor hinter Intellisense, Autovervollständigung, Typ-Prüfung und Refactoring. Ohne Pylance (oder einen gleichwertigen Pyright-basierten Server) sind Python-Dateien für VS Code im Grunde „blindes Text".

Ruff ist das Linting- und Formatting-Tool — geschrieben in Rust, extrem schnell, und als Replacement für flake8, pylint, isort, pyupgrade und Black konzipiert. Alles in einem einzigen Binary.

---

Wo kommen die Einstellungen hin?

Faustregel: Tool-Präferenzen (Was verwende ich?) → User Settings. Projekt-Verhalten (Wie streng?) → Workspace Settings.

In meinem Setup nutze ich diese Entlastung bewusst global in den User Settings. Für Teams oder Repositories mit stark abweichenden Standards kann Workspace-Scoping trotzdem der bessere Kompromiss sein.

In den Settings-Dateien konkret

User Settings (%APPDATA%\Code\User\settings.json):

{
  "ruff.nativeServer": "on",
  "python.languageServer": "Pylance",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true
  }
}

Auch hier gilt: Die Formatter-Zuweisung funktioniert nur, wenn die Extension charliermarsh.ruff tatsächlich installiert ist.

Workspace Settings (.vscode/settings.json im Projektordner):

{
  "python.analysis.typeCheckingMode": "basic",
  "python.analysis.diagnosticMode": "openFilesOnly",
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python"
}

---

Ruff installieren: global oder lokal?

Empfehlung: beides — globale CLI + lokales Binary im venv.

Global (für alle Projekte, ohne venv-Konflikt):

# Mit pipx — empfohlen, weil isoliert:
pipx install ruff

# Oder klassisch global:
pip install ruff

Projektlokal (im venv des Projekts):

# Im aktivierten venv:
pip install ruff

Oder als Dev-Abhängigkeit in pyproject.toml:

[project.optional-dependencies]
dev = ["ruff>=0.4.0"]

VS Code Extension (charliermarsh.ruff)

Voraussetzung: Die VS-Code-Extension charliermarsh.ruff muss installiert sein. Die reine Zuweisung editor.defaultFormatter = charliermarsh.ruff reicht nicht, wenn die Extension fehlt.

Empfohlener Eintrag in die VS-Code-User-Settings (%APPDATA%\Code\User\settings.json):

In meinem Setup ist zusätzlich der native Ruff-Server aktiviert:

{
  "ruff.nativeServer": "on",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff"
  }
}

Die Extension wird in den User Settings aktiviert — einmal, global. Sie erkennt automatisch die Priorität:

1. Projekteigenes ruff-Binary im venv → wird bevorzugt
2. Global via pipx installiertes ruff
3. Letzter Fallback: das in der Extension mitgelieferte Bundled-Binary

ext install charliermarsh.ruff

---

Empfohlenes Setup 2026

1. Extensions installieren: ms-python.vscode-pylance + charliermarsh.ruff
2. Pylance-Linting reduzieren (Ruff übernimmt das):

   "python.analysis.diagnosticMode": "openFilesOnly"

3. Ruff als Formatter (User Settings, einmal global)
4. Pro Projekt: pyproject.toml oder ruff.toml für Lint-Regeln

# pyproject.toml — Ruff-Konfiguration
[tool.ruff]
line-length = 120
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "UP"]  # flake8 + isort + pyupgrade
ignore = ["E501"]                # line length per formatter

---

Copyright & Datum

Das Blog-Datum (21. März 2026) ist im Frontmatter hinterlegt und wird vom Template ausgewertet. Der Autor und das Copyright (© 2026 Nejat Philip Eryigit · ready-4-IT.com) stammen aus der globalen site.yaml und erscheinen im Seiten-Footer.

---

Fazit: Pylance dauerhaft an — richtig konfiguriert

Kurz: Pylance nicht deaktivieren, sondern richtig konfigurieren. Wer Pylance „bei Bedarf" ein- und ausschaltet, schafft sich unnötige Arbeit ohne echten Vorteil.

Pylance ist der Motor hinter Intellisense, Hover-Docs, Go-to-Definition und Refactoring — Features, die VS Code zur echten Entwicklungsumgebung machen. Bei korrekter Konfiguration verursacht er kaum Mehraufwand.

Dauerhaft in den User Settings (einmal, global)

{
  "ruff.nativeServer": "on",
  "python.languageServer": "Pylance",
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true
  }
}

Das ist in meinem aktuellen Setup bewusst userweit gesetzt. Wer in Teams mit unterschiedlichen Vorgaben arbeitet, kann den Scope enger ziehen und projektbezogene Regeln stärker in .vscode/settings.json halten.

Pro Projekt in .vscode/settings.json

{
  "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
  "python.analysis.typeCheckingMode": "basic",
  "python.analysis.diagnosticMode": "openFilesOnly"
}

diagnosticMode: openFilesOnly ist der entscheidende Schalter für Python-Projekte mit vielen Dateien oder externen Abhängigkeiten: Pylance analysiert nur aktuell geöffnete Tabs statt das gesamte Projekt im Hintergrund zu durchsuchen. Das hält den Editor schnell — auch bei größeren Projekten mit Vagrant-Scripts, PHP-Begleitdateien oder geteilten Abhängigkeiten.

Wann Pylance per Workspace deaktivieren?

Nur wenn ein Workspace kein dediziertes venv braucht — z. B. reine Hilfsskripte ohne Typ-Abhängigkeiten. In diesem Fall genügt ein workspace-lokales Override:

{ "python.languageServer": "None" }

Das deaktiviert Pylance nur für diesen Workspace, ohne die globale User-Setting zu verändern.

Die Aufgabenteilung bleibt klar

Aufgabe	Tool	Wo konfigurieren
IntelliSense, Typ-Prüfung, Refactoring	Pylance	User Settings (immer an)
Linting, Formatting, Import-Sort	Ruff	User Settings (immer an)
Strenge der Typ-Prüfung	typeCheckingMode	Workspace Settings
Welches venv	defaultInterpreterPath	Workspace Settings

flake8, pylint, mypy, isort, Black — werden nicht mehr benötigt. Ruff ersetzt alle.

---

© 2026 Nejat Philip Eryigit · ready-4-IT.com · Veröffentlicht: 21. März 2026

---