Python 3.15 ist erschienen: Was Admins beim Umstieg prüfen müssen

Die Python Software Foundation hat am 9. Oktober 2026 Python 3.15.0 veröffentlicht. Neben Lazy Imports, frozendict, sentinel und einem schnelleren, weiterhin experimentellen JIT-Compiler bringt sie eine Änderung, die Betriebsteams direkt trifft: UTF-8 ist jetzt unabhängig von der Systemumgebung Standard-Encoding. Dazu kommen entfernte APIs, an denen ältere Skripte scheitern können.

Akut ist nichts zu tun, es handelt sich um ein Feature-Release ohne Sicherheitsdruck. Wer Python-Anwendungen, Skripte oder Container-Images betreibt, sollte den Umstieg in einem Wartungsfenster vorbereiten und testen. Nicht betroffen sind Umgebungen, die ihre Version fest pinnen. Dringender ist für viele Admins ein Blick auf Altsysteme: Python 3.10 ist seit dem 1. Oktober 2026 end-of-life.

Was ist passiert?

Laut python.org stecken in 3.15.0 gegenüber 3.14 insgesamt 5.643 Commits von 1.012 Mitwirkenden. Die wichtigsten Neuerungen:

• UTF-8 als Standard (PEP 686): Ein-/Ausgabe ohne explizites encoding, etwa open('datei.txt'), nutzt jetzt UTF-8 statt der Locale-Kodierung des Systems.
• Explizite Lazy Imports (PEP 810): Das neue Soft-Keyword lazy verzögert das Laden eines Moduls bis zur ersten Nutzung.
• Neue Builtins: frozendict (PEP 814) ist ein unveränderliches, hashbares Dictionary, sentinel (PEP 661) erzeugt eindeutige Platzhalterwerte.
• Schnellerer JIT: Laut pyperformance liegt der experimentelle JIT auf x86-64 Linux im geometrischen Mittel 7 bis 8 Prozent vor dem Standardinterpreter, auf AArch64 macOS 11 bis 12 Prozent vor dem Tail-Calling-Interpreter. Einzelne Benchmarks laufen aber auch bis zu rund 15 Prozent langsamer.
• Profiling: Das neue Paket profiling enthält den Sampling-Profiler Tachyon, Frame Pointer sind standardmäßig aktiv (PEP 831).
• Startdateien (PEP 829): Neue .start-Dateien lösen ausführbare import-Zeilen in .pth-Dateien ab, die damit stillschweigend als veraltet gelten.

Für wen ist das relevant?

Relevant ist das Release für Entwickler, DevOps-Teams und Admins mit eigenen Python-Skripten, Webanwendungen oder Containern auf Basis der offiziellen Python-Images. Besonders aufmerksam sollten Umgebungen sein, die Dateien in Legacy-Kodierungen wie cp1252 lesen, etwa CSV-Exporte aus Windows-Fachanwendungen. Unter Windows ist der Effekt der Umstellung am größten, weil dort bisher meist eine andere Locale-Kodierung aktiv war.

Wer Python nur über Distributionspakete nutzt, ist vorerst kaum berührt. Wann Linux-Distributionen 3.15 als Systempython ausliefern, geht aus den Quellen nicht hervor.

Wie kritisch ist das?

Sicherheitstechnisch ist das Release unkritisch, operativ nicht trivial. Die UTF-8-Umstellung ändert stillschweigend das Verhalten von Code ohne explizite Kodierung: Es drohen falsch gelesene Umlaute oder ein UnicodeDecodeError mitten im Lauf. Laut Python-Dokumentation lässt sich das alte Verhalten mit PYTHONUTF8=0 oder -X utf8=0 wiederherstellen, empfohlen wird aber, das encoding-Argument immer explizit anzugeben.

Daneben entfernt 3.15 mehrere seit Jahren als veraltet markierte Schnittstellen, darunter die Module sre_compile, sre_constants und sre_parse, die Klasse CGIHTTPRequestHandler samt --cgi-Option von python -m http.server, die load_module()-Methoden in importlib und zipimport sowie platform.java_ver(). Zudem wirft datetime.strptime() bei %d ohne Jahr nun einen ValueError. Das Modul profile ist neu als veraltet markiert und soll mit Python 3.17 entfallen.

Was sollten Admins jetzt tun?

• Inventar erstellen: Python-Versionen auf Servern, in Images und CI-Pipelines erfassen, etwa per python3 --version, und Dockerfiles nach FROM python:-Zeilen durchsuchen. Systeme mit Python 3.10 haben Vorrang, diese Version bekommt seit dem 1. Oktober 2026 keine Sicherheitsupdates mehr.
• Encoding prüfen: Tests mit -X warn_default_encoding laufen lassen, um Aufrufe ohne explizite Kodierung als EncodingWarning sichtbar zu machen, und betroffene Stellen mit encoding= ergänzen.
• Entfernte APIs suchen: Code per grep nach sre_parse, CGIHTTPRequestHandler und load_module durchsuchen, Tests unter 3.14 mit -W error::DeprecationWarning ausführen.
• Container-Tags kontrollieren: Bei einer Abfrage der Docker-Hub-API in der Nacht zum 10. Oktober 2026 gab es für das offizielle Image nur 3.15-rc, 3.15-rc-slim und 3.15.0rc3, ein Tag python:3.15 war noch nicht vorhanden. python:latest und python:3 zeigten auf denselben Digest wie python:3.14. Erscheinen die finalen Tags, dürften diese beiden Tags auf 3.15 wechseln, daher die Minor-Version pinnen.
• Abhängigkeiten prüfen: Pakete mit C-Erweiterungen brauchen Wheels für 3.15.
• Startcode in .pth-Dateien auditieren: In site-packages nach .pth-Dateien mit import-Zeilen suchen, denn diese führen beim Interpreterstart Code aus.

Einordnung für Unternehmen

Laut PEP 790 erhält Python 3.15 etwa zwei Jahre lang Bugfix-Releases im Abstand von rund zwei Monaten, danach Sicherheitsupdates als Quellcode bis etwa Oktober 2031. Laut Python Developer's Guide enden die übrigen Zweige im Oktober 2030 (3.14), 2029 (3.13), 2028 (3.12) und 2027 (3.11). Wer auf 3.11 steht, sollte die Migration im kommenden Jahr einplanen. Ein sofortiger Sprung auf 3.15 ist für die meisten Unternehmen nicht nötig, sinnvoll ist aber ein paralleler Testlauf in der CI, damit Encoding- und API-Probleme früh auffallen.

Hintergrund zur letzten größeren Lücke in der Standardbibliothek bietet die S-EDV-Meldung zum tarfile-Bypass CVE-2026-11940.

Passende Anleitungen auf S-EDV

• Docker-Images mit Trivy scannen: Basisimages und Pakete auf Schwachstellen prüfen.
• Renovate als Dependency-Updater: Image-Tags wie python:3.14 kontrolliert per Pull Request aktualisieren statt über latest.
• Docker-Compose-Grundlagen: Stacks mit festen Image-Versionen aufbauen.

Quellen

• Python-Dokumentation: Neuerungen in Python 3.15
• python.org: Release-Seite zu Python 3.15.0
• PEP 790: Zeitplan und Supportdauer von Python 3.15
• Python Developer's Guide: Status der Python-Versionen
• Phoronix: Bericht zur Veröffentlichung von Python 3.15
• LWN.net: Meldung zu Python 3.15
• Docker Hub: offizielles Python-Image