Was ist neu in Python 3.14

Herausgeber:

Adam Turner und Hugo van Kemenade

Dieser Artikel erklärt die neuen Features in Python 3.14 im Vergleich zu 3.13. Python 3.14 wurde am 7. Oktober 2025 veröffentlicht. Alle Einzelheiten stehen im Änderungsprotokoll.

Siehe auch

PEP 745 – Zeitplan für die Veröffentlichung von Python 3.14

Zusammenfassung - Release Höhepunkte

Python 3.14 is a stable release of the Python programming language, with a mix of changes to the language, the implementation, and the standard library. The biggest changes include template string literals, deferred evaluation of annotations, and support for subinterpreters in the standard library.

Zu den Änderungen an der Bibliothek gehören deutlich bessere Möglichkeiten zur Introspektion in asyncio, die Unterstützung für Zstandard über das neue Modul compression.zstd, Syntaxhervorhebung in der REPL sowie die üblichen Abkündigungen und Entfernungen und Verbesserungen bei Benutzerfreundlichkeit und Korrektheit.

Dieser Artikel versucht nicht, eine vollständige Spezifikation aller neuen Features zu liefern, sondern gibt einen handlichen Überblick. Alle Einzelheiten stehen in der Dokumentation, etwa in der Bibliotheksreferenz und der Sprachreferenz. Um die vollständige Implementierung und die Entwurfsgründe einer Änderung zu verstehen, sieh im PEP zum jeweiligen neuen Feature nach. Beachte aber, dass PEPs in der Regel nicht mehr aktualisiert werden, sobald ein Feature vollständig umgesetzt ist. Hinweise zum Umstieg von früheren Python-Versionen findest du unter Portierung auf Python 3.14.

Verbesserungen am Interpreter:

Wesentliche Verbesserungen in der Standardbibliothek:

Verbesserungen der C-API:

Unterstützte Plattformen:

Änderungen an den Releases:

Neue Features

PEP 649 & PEP 749: Verzögerte Auswertung von Annotationen

Die Annotationen an Funktionen, Klassen und Modulen werden nicht mehr sofort ausgewertet. Stattdessen werden Annotationen in besonderen Annotate-Funktionen gespeichert und erst dann ausgewertet, wenn es nötig ist (außer wenn from __future__ import annotations verwendet wird).

Diese Änderung soll die Geschwindigkeit und die Handhabung von Annotationen in Python in den meisten Fällen verbessern. Die Laufzeitkosten für das Festlegen von Annotationen sinken auf ein Minimum, es bleibt aber möglich, Annotationen zur Laufzeit zu untersuchen. Annotationen müssen nicht mehr in Zeichenketten eingeschlossen werden, wenn sie Vorwärtsreferenzen enthalten.

Das neue Modul annotationlib bietet Werkzeuge, um verzögerte Annotationen zu untersuchen. Annotationen lassen sich im Format VALUE auswerten (das Annotationen zu Laufzeitwerten auswertet, ähnlich wie in früheren Python-Versionen), im Format FORWARDREF (das nicht definierte Namen durch besondere Markierungen ersetzt) und im Format STRING (das Annotationen als Zeichenketten zurückgibt).

Dieses Beispiel zeigt, wie sich diese Formate verhalten:

>>> from annotationlib import get_annotations, Format
>>> def func(arg: Undefined):
...     pass
>>> get_annotations(func, format=Format.VALUE)
Traceback (most recent call last):
  ...
NameError: name 'Undefined' is not defined
>>> get_annotations(func, format=Format.FORWARDREF)
{'arg': ForwardRef('Undefined', owner=<function func at 0x...>)}
>>> get_annotations(func, format=Format.STRING)
{'arg': 'Undefined'}

Der Abschnitt zur Portierung enthält Hinweise zu Änderungen, die wegen dieser Umstellung nötig sein können. In der großen Mehrheit der Fälle funktioniert bestehender Code aber unverändert weiter.

(Beigetragen von Jelle Zijlstra in PEP 749 und gh-119180; PEP 649 wurde von Larry Hastings verfasst.)

Siehe auch

PEP 649

Verzögerte Auswertung von Annotationen mithilfe von Deskriptoren

PEP 749

PEP 649 umsetzen

PEP 734: Mehrere Interpreter in der Standardbibliothek

Die CPython-Laufzeitumgebung kann mehrere Kopien von Python gleichzeitig im selben Prozess ausführen, und das seit über 20 Jahren. Jede dieser getrennten Kopien heißt „Interpreter“. Verfügbar war das Feature allerdings nur über die C-API.

Diese Einschränkung fällt in Python 3.14 mit dem neuen Modul concurrent.interpreters weg.

Es gibt mindestens zwei bemerkenswerte Gründe, warum mehrere Interpreter deutliche Vorteile bringen:

  • Sie unterstützen ein (für Python) neues, menschenfreundliches Modell für Nebenläufigkeit

  • echte Mehrkern-Parallelität

In manchen Anwendungsfällen verbessert Nebenläufigkeit in Software die Effizienz und kann den Entwurf auf höherer Ebene vereinfachen. Gleichzeitig ist alles, was über die einfachste Nebenläufigkeit hinausgeht, für das menschliche Gehirn oft eine Qual – beim Umsetzen und beim Pflegen. Das gilt besonders für gewöhnliche Threads (zum Beispiel threading), bei denen der gesamte Speicher von allen Threads gemeinsam genutzt wird.

Mit mehreren voneinander abgeschirmten Interpretern kannst du eine Klasse von Nebenläufigkeitsmodellen nutzen, die sich in anderen Programmiersprachen wie Smalltalk, Erlang, Haskell und Go bewährt hat, etwa Communicating Sequential Processes (CSP) oder das Aktorenmodell. Stell dir mehrere Interpreter als Threads vor, bei denen das Teilen aber ausdrücklich gewählt wird.

Zur Mehrkern-Parallelität: Seit Python 3.12 sind Interpreter so weit voneinander abgeschirmt, dass sie parallel genutzt werden können (siehe PEP 684). Das erschließt für Python eine ganze Reihe rechenintensiver Anwendungsfälle, die vorher durch den GIL beschränkt waren.

Mehrere Interpreter zu verwenden ähnelt in vielerlei Hinsicht multiprocessing, denn beide bieten abgeschirmte logische „Prozesse“, die parallel laufen können und sich von sich aus nichts teilen. Mit mehreren Interpretern verbraucht eine Anwendung allerdings weniger Systemressourcen und arbeitet effizienter, weil sie innerhalb desselben Prozesses bleibt. Stell dir mehrere Interpreter so vor, dass sie die Abschirmung von Prozessen mit der Effizienz von Threads verbinden.

Das Feature gibt es zwar schon seit Jahrzehnten, mehrere Interpreter wurden aber kaum verwendet, weil sie wenig bekannt waren und ein Modul in der Standardbibliothek fehlte. Deshalb haben sie derzeit einige bemerkenswerte Einschränkungen, die sich nun, da das Feature in die Breite geht, voraussichtlich deutlich verbessern werden.

Derzeitige Einschränkungen:

  • Der Start jedes Interpreters ist noch nicht optimiert

  • Jeder Interpreter verbraucht mehr Speicher als nötig (an umfangreichem internem Teilen zwischen Interpretern wird weiter gearbeitet)

  • Es gibt noch nicht viele Möglichkeiten, Objekte oder andere Daten wirklich zwischen Interpretern zu teilen (außer memoryview)

  • Viele Erweiterungsmodule Dritter auf PyPI sind noch nicht mit mehreren Interpretern verträglich (alle Erweiterungsmodule der Standardbibliothek sind es)

  • Wie man Anwendungen schreibt, die mehrere abgeschirmte Interpreter verwenden, ist Python-Nutzern bislang weitgehend unbekannt

Wie stark diese Einschränkungen wiegen, hängt von künftigen Verbesserungen in CPython ab, davon, wie Interpreter genutzt werden, und davon, was die Gemeinschaft über PyPI-Pakete löst. Je nach Anwendungsfall fallen die Einschränkungen kaum ins Gewicht – probiere es also aus!

Künftige CPython-Ausgaben werden den Zusatzaufwand außerdem verringern oder beseitigen und Hilfsmittel bereitstellen, die auf PyPI weniger gut aufgehoben sind. Bis dahin lassen sich die meisten Einschränkungen auch über Erweiterungsmodule angehen; PyPI-Pakete können also jede Lücke für 3.14 füllen, und sogar zurück bis 3.12, wo Interpreter endlich richtig abgeschirmt wurden und sich den GIL nicht mehr teilten. Ebenso ist zu erwarten, dass auf PyPI Bibliotheken für Abstraktionen auf höherer Ebene über Interpretern entstehen.

Zu den Erweiterungsmodulen: An der Aktualisierung einiger PyPI-Projekte sowie von Werkzeugen wie Cython, pybind11, nanobind und PyO3 wird gearbeitet. Die Schritte zum Abschirmen eines Erweiterungsmoduls stehen unter Erweiterungsmodule isolieren. Ein Modul abzuschirmen überschneidet sich stark mit dem, was für die Unterstützung von Free-Threading nötig ist. Die laufende Arbeit der Gemeinschaft in diesem Bereich beschleunigt daher auch die Unterstützung mehrerer Interpreter.

Ebenfalls neu in 3.14: concurrent.futures.InterpreterPoolExecutor.

(Beigetragen von Eric Snow in gh-134939.)

Siehe auch

PEP 734

PEP 750: Template-String-Literale

Template-Strings sind ein neuer Mechanismus für die eigene Verarbeitung von Zeichenketten. Sie haben dieselbe gewohnte Syntax wie f-Strings, geben aber anders als diese kein einfaches str zurück, sondern ein Objekt, das die festen und die eingesetzten Teile der Zeichenkette darstellt.

Um einen t-String zu schreiben, nimm das Präfix 't' statt 'f':

>>> variety = 'Stilton'
>>> template = t'Try some {variety} cheese!'
>>> type(template)
<class 'string.templatelib.Template'>

Template-Objekte geben Zugriff auf die festen und die (in geschweiften Klammern) eingesetzten Teile einer Zeichenkette, bevor sie zusammengesetzt werden. Iteriere über Template-Instanzen, um der Reihe nach auf ihre Teile zuzugreifen:

>>> list(template)
['Try some ', Interpolation('Stilton', 'variety', None, ''), ' cheese!']

Code zu schreiben (oder aufzurufen), der Template-Instanzen verarbeitet, ist einfach. Hier zum Beispiel eine Funktion, die feste Teile in Kleinbuchstaben und Interpolation-Instanzen in Großbuchstaben darstellt:

from string.templatelib import Interpolation

def lower_upper(template):
    """Render static parts lowercase and interpolations uppercase."""
    parts = []
    for part in template:
        if isinstance(part, Interpolation):
            parts.append(str(part.value).upper())
        else:
            parts.append(part.lower())
    return ''.join(parts)

name = 'Wenslydale'
template = t'Mister {name}'
assert lower_upper(template) == 'mister WENSLYDALE'

Weil Template-Instanzen zur Laufzeit zwischen festen Zeichenketten und eingesetzten Werten unterscheiden, können sie beim Säubern von Benutzereingaben nützlich sein. Eine Funktion html() zu schreiben, die Benutzereingaben für HTML maskiert, bleibt eine Übung für den Leser! Code zur Template-Verarbeitung kann für mehr Flexibilität sorgen. Eine ausgefeiltere Funktion html() könnte zum Beispiel ein dict mit HTML-Attributen unmittelbar im Template annehmen:

attributes = {'src': 'limburger.jpg', 'alt': 'lovely cheese'}
template = t'<img {attributes}>'
assert html(template) == '<img src="limburger.jpg" alt="lovely cheese" />'

Natürlich muss Code zur Template-Verarbeitung kein zeichenkettenartiges Ergebnis zurückgeben. Eine noch ausgefeiltere Funktion html() könnte einen eigenen Typ zurückgeben, der eine DOM-artige Struktur darstellt.

Mit t-Strings können Entwickler Systeme schreiben, die SQL säubern, sichere Shell-Operationen ermöglichen, die Protokollierung verbessern, moderne Ideen der Webentwicklung aufgreifen (HTML, CSS und so weiter) und leichtgewichtige, fachlich zugeschnittene Sprachen umsetzen.

(Beigetragen von Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou, Dave Peck, Adam Turner, Jelle Zijlstra, Bénédikt Tran und Pablo Galindo Salgado in gh-132661.)

Siehe auch

PEP 750.

PEP 768: Sichere Schnittstelle für externe Debugger

Python 3.14 führt eine Debugging-Schnittstelle ohne Zusatzaufwand ein, über die sich Debugger und Profiler sicher an laufende Python-Prozesse anhängen können, ohne sie anzuhalten oder neu zu starten. Das erweitert Pythons Möglichkeiten zur Fehlersuche erheblich, denn unsichere Behelfslösungen sind damit nicht mehr nötig.

Die neue Schnittstelle bietet sichere Ausführungspunkte, an denen sich Debugger-Code anhängen lässt, ohne den normalen Ausführungsweg des Interpreters zu verändern oder zur Laufzeit Zusatzaufwand zu verursachen. Werkzeuge können Python-Anwendungen dadurch in Echtzeit untersuchen und mit ihnen umgehen – eine entscheidende Fähigkeit für hochverfügbare Systeme und Produktivumgebungen.

Zur Bequemlichkeit ist diese Schnittstelle in der Funktion sys.remote_exec() umgesetzt. Zum Beispiel:

import sys
from tempfile import NamedTemporaryFile

with NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f:
    script_path = f.name
    f.write(f'import my_debugger; my_debugger.connect({os.getpid()})')

# Execute in process with PID 1234
print('Behold! An offering:')
sys.remote_exec(1234, script_path)

Mit dieser Funktion lässt sich Python-Code senden, der im Zielprozess am nächsten sicheren Ausführungspunkt ausgeführt wird. Wer Werkzeuge schreibt, kann das Protokoll aber auch unmittelbar umsetzen, wie im PEP beschrieben. Dort sind die zugrunde liegenden Mechanismen für das sichere Anhängen an laufende Prozesse ausgeführt.

Die Debugging-Schnittstelle wurde mit Blick auf Sicherheit sorgfältig entworfen und enthält mehrere Mechanismen, um den Zugriff zu steuern:

(Beigetragen von Pablo Galindo Salgado, Matt Wozniski und Ivona Stojanovic in gh-131591.)

Siehe auch

PEP 768.

Eine neue Art von Interpreter

CPython hat eine neue Art von Interpreter erhalten. Er verwendet Endaufrufe zwischen kleinen C-Funktionen, die die einzelnen Python-Opcodes umsetzen, statt einer großen case-Anweisung in C. Mit bestimmten neueren Compilern ist dieser Interpreter deutlich schneller. Vorläufige Messungen deuten je nach Plattform und Architektur auf ein geometrisches Mittel von 3 bis 5 % Geschwindigkeitsgewinn in der üblichen Benchmark-Sammlung pyperformance. Grundlage des Vergleichs ist Python 3.14, mit Clang 19 gebaut, ohne diesen neuen Interpreter.

Dieser Interpreter funktioniert derzeit nur mit Clang 19 und neuer auf den Architekturen x86-64 und AArch64. Eine künftige GCC-Ausgabe wird das aber voraussichtlich ebenfalls unterstützen.

Dieses Feature muss man vorläufig ausdrücklich einschalten. Beim neuen Interpreter ist die profilgesteuerte Optimierung dringend zu empfehlen, denn nur diese Konfiguration wurde auf den Geschwindigkeitsgewinn hin getestet und bestätigt. Näheres unter --with-tail-call-interp.

Bemerkung

Das ist nicht mit der tail call optimization von Python-Funktionen zu verwechseln, die in CPython derzeit nicht umgesetzt ist.

Diese neue Art von Interpreter ist ein internes Umsetzungsdetail des CPython-Interpreters. Am sichtbaren Verhalten von Python-Programmen ändert sie überhaupt nichts. Sie kann deren Geschwindigkeit verbessern, ändert aber nichts weiter.

(Beigetragen von Ken Jin in gh-128563, mit Ideen zur Umsetzung in CPython von Mark Shannon, Garrett Gu, Haoran Xu und Josh Haberman.)

Verbesserungen im Free-Threaded-Modus

CPythons Free-Threaded-Modus (PEP 703), erstmals in 3.13 hinzugekommen, wurde in Python 3.14 deutlich verbessert. Die in PEP 703 beschriebene Umsetzung ist abgeschlossen, einschließlich der Änderungen an der C-API, und vorläufige Behelfslösungen im Interpreter wurden durch dauerhaftere ersetzt. Der spezialisierende, anpassungsfähige Interpreter (PEP 659) ist im Free-Threaded-Modus jetzt eingeschaltet, was zusammen mit vielen weiteren Optimierungen dessen Geschwindigkeit stark verbessert. Der Geschwindigkeitsverlust bei einsträngigem Code im Free-Threaded-Modus liegt jetzt je nach Plattform und verwendetem C-Compiler bei etwa 5 bis 10 %.

Ab Python 3.14 muss beim Übersetzen von Erweiterungsmodulen für den Free-Threaded-Build von CPython unter Windows die Präprozessorvariable Py_GIL_DISABLED vom Build-Backend angegeben werden, denn der C-Compiler bestimmt sie nicht mehr selbst. Bei einem laufenden Interpreter lässt sich die zur Übersetzungszeit verwendete Einstellung mit sysconfig.get_config_var() abfragen.

Der neue Schalter -X context_aware_warnings steuert, ob die nebenläufigkeitssichere Steuerung von Warnungen eingeschaltet ist. Der Schalter ist beim Free-Threaded-Build standardmäßig wahr und beim Build mit eingeschaltetem GIL falsch.

Ein neuer Schalter thread_inherit_context ist hinzugekommen. Ist er eingeschaltet, starten mit threading.Thread erzeugte Threads mit einer Kopie des Context() desjenigen, der start() aufgerufen hat. Vor allem wird damit der durch catch_warnings eingerichtete Kontext zum Filtern von Warnungen an Threads (oder asyncio-Aufträge) „vererbt“, die innerhalb dieses Kontexts gestartet werden. Es betrifft auch andere Module, die Kontextvariablen verwenden, etwa den Kontextmanager von decimal. Dieser Schalter ist beim Free-Threaded-Build standardmäßig wahr und beim Build mit eingeschaltetem GIL falsch.

(Beigetragen von Sam Gross, Matt Page, Neil Schemenauer, Thomas Wouters, Donghee Na, Kirill Podoprigora, Ken Jin, Itamar Oren, Brett Simmers, Dino Viehland, Nathan Goldbaum, Ralf Gommers, Lysandros Nikolaou, Kumar Aditya, Edgar Margffoy und viele weitere. Einige dieser Beitragenden sind bei Meta angestellt, das dieses Projekt weiterhin mit erheblichen Entwicklungsressourcen unterstützt.)

Verbesserte Fehlermeldungen

  • Der Interpreter gibt jetzt hilfreiche Vorschläge, wenn er Tippfehler in Python-Schlüsselwörtern erkennt. Trifft er auf ein Wort, das einem Python-Schlüsselwort stark ähnelt, schlägt er in der Fehlermeldung das richtige Schlüsselwort vor. Dieses Feature hilft Programmierern, häufige Tippfehler schnell zu finden und zu beheben. Zum Beispiel:

    >>> whille True:
...     pass
Traceback (most recent call last):
  File "<stdin>", line 1
    whille True:
    ^^^^^^
SyntaxError: invalid syntax. Did you mean 'while'?

    Das Feature zielt auf die häufigsten Fälle. Manche Varianten von Schreibfehlern führen weiterhin zu gewöhnlichen Syntaxfehlern. (Beigetragen von Pablo Galindo in gh-132449.)

  • elif-Anweisungen, die auf einen else-Block folgen, haben jetzt eine eigene Fehlermeldung. (Beigetragen von Steele Farnsworth in gh-129902.)

    >>> if who == "me":
...     print("It's me!")
... else:
...     print("It's not me!")
... elif who is None:
...     print("Who is it?")
File "<stdin>", line 5
  elif who is None:
  ^^^^
SyntaxError: 'elif' block follows an 'else' block

  • Wird dem Bedingte Ausdrücke nach else eine Anweisung übergeben oder vor if eines von pass, break oder continue, dann hebt die Fehlermeldung hervor, wo der expression nötig ist. (Beigetragen von Sergey Miryanov in gh-129515.)

    >>> x = 1 if True else pass
Traceback (most recent call last):
  File "<string>", line 1
    x = 1 if True else pass
                       ^^^^
SyntaxError: expected expression after 'else', but statement is given

>>> x = continue if True else break
Traceback (most recent call last):
  File "<string>", line 1
    x = continue if True else break
        ^^^^^^^^
SyntaxError: expected expression before 'if', but statement is given

  • Werden falsch beendete Zeichenketten erkannt, legt die Fehlermeldung nahe, dass die Zeichenkette Teil der Zeichenkette sein soll. (Beigetragen von Pablo Galindo in gh-88535.)

    >>> "The interesting object "The important object" is very important"
Traceback (most recent call last):
SyntaxError: invalid syntax. Is this intended to be part of the string?

  • Haben Zeichenketten unverträgliche Präfixe, zeigt der Fehler jetzt, welche Präfixe unverträglich sind. (Beigetragen von Nikita Sobolev in gh-133197.)

    >>> ub'abc'
  File "<python-input-0>", line 1
    ub'abc'
    ^^
SyntaxError: 'u' and 'b' prefixes are incompatible

  • Verbesserte Fehlermeldungen bei der Verwendung von as mit unverträglichen Zielen in:

    • Importen: import ... as ...

    • From-Importen: from ... import ... as ...

    • Except-Handlern: except ... as ...

    • Fällen des Musterabgleichs: case ... as ...

    (Beigetragen von Nikita Sobolev in gh-123539, gh-123562 und gh-123440.)

  • Verbesserte Fehlermeldung beim Versuch, eine Instanz eines nicht hashbaren Typs zu einem dict oder set hinzuzufügen. (Beigetragen von CF Bolz-Tereick und Victor Stinner in gh-132828.)

    >>> s = set()
>>> s.add({'pages': 12, 'grade': 'A'})
Traceback (most recent call last):
  File "<python-input-1>", line 1, in <module>
    s.add({'pages': 12, 'grade': 'A'})
    ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cannot use 'dict' as a set element (unhashable type: 'dict')
>>> d = {}
>>> l = [1, 2, 3]
>>> d[l] = 12
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    d[l] = 12
    ~^^^
TypeError: cannot use 'list' as a dict key (unhashable type: 'list')

  • Verbesserte Fehlermeldung, wenn ein Objekt, das das Protokoll für synchrone Kontextmanager unterstützt, mit async with statt mit with betreten wird, und umgekehrt beim Protokoll für asynchrone Kontextmanager. (Beigetragen von Bénédikt Tran in gh-128398.)

PEP 784: Zstandard-Unterstützung in der Standardbibliothek

Das neue Paket compression enthält die Module compression.lzma, compression.bz2, compression.gzip und compression.zlib, die jeweils die Module lzma, bz2, gzip und zlib erneut exportieren. Die neuen Importnamen unter compression sind ab Python 3.14 die bevorzugten Namen, um diese Kompressionsmodule zu importieren. Die bestehenden Modulnamen wurden allerdings nicht als veraltet markiert. Eine Abkündigung oder Entfernung der bestehenden Kompressionsmodule erfolgt frühestens fünf Jahre nach der Veröffentlichung von 3.14.

Das neue Modul compression.zstd bietet APIs zum Komprimieren und Entpacken des Zstandard-Formats über eine Anbindung an Metas zstd-Bibliothek. Zstandard ist ein weit verbreitetes, höchst effizientes und schnelles Kompressionsformat. Neben den in compression.zstd eingeführten APIs wurde den Modulen tarfile, zipfile und shutil die Unterstützung zum Lesen und Schreiben Zstandard-komprimierter Archive hinzugefügt.

Hier ein Beispiel, wie sich mit dem neuen Modul Daten komprimieren lassen:

from compression import zstd
import math

data = str(math.pi).encode() * 20
compressed = zstd.compress(data)
ratio = len(compressed) / len(data)
print(f"Achieved compression ratio of {ratio}")

Wie zu sehen ist, ähnelt die API den APIs der Module lzma und bz2.

(Beigetragen von Emma Harper Smith, Adam Turner, Gregory P. Smith, Tomas Roun, Victor Stinner und Rogdham in gh-132983.)

Siehe auch

PEP 784.

Möglichkeiten zur Introspektion in asyncio

Eine neue Befehlszeilenschnittstelle ist hinzugekommen, mit der sich laufende Python-Prozesse untersuchen lassen, die asynchrone Aufträge verwenden. Verfügbar über python -m asyncio ps PID oder python -m asyncio pstree PID.

Der Unterbefehl ps untersucht die angegebene Prozesskennung (PID) und zeigt Informationen über die derzeit laufenden asyncio-Aufträge an. Er gibt eine Auftragstabelle aus: eine flache Auflistung aller Aufträge, ihrer Namen, ihrer Coroutine-Stapel und derjenigen Aufträge, die auf sie warten.

Der Unterbefehl pstree holt dieselben Informationen, stellt aber stattdessen einen anschaulichen asynchronen Aufrufbaum dar, der die Beziehungen der Coroutinen hierarchisch zeigt. Dieser Befehl ist besonders nützlich, um lange laufende oder hängende asynchrone Programme zu untersuchen. Er hilft Entwicklern, schnell zu erkennen, wo ein Programm blockiert, welche Aufträge noch ausstehen und wie die Coroutinen aneinandergekettet sind.

Zum Beispiel bei diesem Code:

import asyncio

async def play_track(track):
    await asyncio.sleep(5)
    print(f'🎵 Finished: {track}')

async def play_album(name, tracks):
    async with asyncio.TaskGroup() as tg:
        for track in tracks:
            tg.create_task(play_track(track), name=track)

async def main():
    async with asyncio.TaskGroup() as tg:
        tg.create_task(
          play_album('Sundowning', ['TNDNBTG', 'Levitate']),
          name='Sundowning')
        tg.create_task(
          play_album('TMBTE', ['DYWTYLM', 'Aqua Regia']),
          name='TMBTE')

if __name__ == '__main__':
    asyncio.run(main())

Das neue Werkzeug auf den laufenden Prozess angewendet ergibt eine Tabelle wie diese:

python -m asyncio ps 12345

tid        task id              task name            coroutine stack                                    awaiter chain                                      awaiter name    awaiter id
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1935500    0x7fc930c18050       Task-1               TaskGroup._aexit -> TaskGroup.__aexit__ -> main                                                                       0x0
1935500    0x7fc930c18230       Sundowning           TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TaskGroup._aexit -> TaskGroup.__aexit__ -> main    Task-1          0x7fc930c18050
1935500    0x7fc93173fa50       TMBTE                TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TaskGroup._aexit -> TaskGroup.__aexit__ -> main    Task-1          0x7fc930c18050
1935500    0x7fc93173fdf0       TNDNBTG              sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   Sundowning      0x7fc930c18230
1935500    0x7fc930d32510       Levitate             sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   Sundowning      0x7fc930c18230
1935500    0x7fc930d32890       DYWTYLM              sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TMBTE           0x7fc93173fa50
1935500    0x7fc93161ec30       Aqua Regia           sleep -> play                                      TaskGroup._aexit -> TaskGroup.__aexit__ -> album   TMBTE           0x7fc93173fa50

oder einen Baum wie diesen:

python -m asyncio pstree 12345

└── (T) Task-1
    └──  main example.py:13
        └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
            └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                ├── (T) Sundowning
                │   └──  album example.py:8
                │       └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
                │           └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                │               ├── (T) TNDNBTG
                │               │   └──  play example.py:4
                │               │       └──  sleep Lib/asyncio/tasks.py:702
                │               └── (T) Levitate
                │                   └──  play example.py:4
                │                       └──  sleep Lib/asyncio/tasks.py:702
                └── (T) TMBTE
                    └──  album example.py:8
                        └──  TaskGroup.__aexit__ Lib/asyncio/taskgroups.py:72
                            └──  TaskGroup._aexit Lib/asyncio/taskgroups.py:121
                                ├── (T) DYWTYLM
                                │   └──  play example.py:4
                                │       └──  sleep Lib/asyncio/tasks.py:702
                                └── (T) Aqua Regia
                                    └──  play example.py:4
                                        └──  sleep Lib/asyncio/tasks.py:702

Wird im Graphen der asynchronen await-Beziehungen ein Zyklus erkannt (was auf ein Problem im Programm hindeuten kann), löst das Werkzeug einen Fehler aus und listet die Zyklenpfade auf, die den Aufbau des Baums verhindern:

python -m asyncio pstree 12345

ERROR: await-graph contains cycles - cannot print a tree!

cycle: Task-2 → Task-3 → Task-2

(Beigetragen von Pablo Galindo, Łukasz Langa, Yury Selivanov und Marta Gomez Macias in gh-91048.)

Nebenläufigkeitssichere Steuerung von Warnungen

Der Kontextmanager warnings.catch_warnings verwendet für die Warnungsfilter jetzt wahlweise eine Kontextvariable. Eingeschaltet wird das über den Schalter context_aware_warnings, entweder mit der Befehlszeilenoption -X oder über eine Umgebungsvariable. Damit lassen sich Warnungen auch dann vorhersehbar steuern, wenn catch_warnings mit mehreren Threads oder asynchronen Aufträgen zusammenkommt. Der Schalter ist beim Free-Threaded-Build standardmäßig wahr und beim Build mit eingeschaltetem GIL falsch.

(Beigetragen von Neil Schemenauer und Kumar Aditya in gh-130010.)

Weitere Sprachänderungen

  • Alle Windows-Codepages werden unter Windows jetzt als Codecs „cpXXX“ unterstützt. (Beigetragen von Serhiy Storchaka in gh-123803.)

  • Die Regeln für gemischte Arithmetik aus reellen und komplexen Zahlen sind jetzt so umgesetzt, wie sie der C-Standard seit C99 vorgibt. (Beigetragen von Sergey B Kirpichev in gh-69639.)

  • Mehr Syntaxfehler werden jetzt unabhängig von der Optimierung und von der Befehlszeilenoption -O erkannt. Dazu gehören Schreibzugriffe auf __debug__, die falsche Verwendung von await und asynchrone Comprehensions außerhalb asynchroner Funktionen. python -O -c 'assert (__debug__ := 1)' oder python -O -c 'assert await 1' erzeugen jetzt zum Beispiel SyntaxErrors. (Beigetragen von Irit Katriel und Jelle Zijlstra in gh-122245 & gh-121637.)

  • Wird von einem reinen C-Typ abgeleitet, werden die C-Slots des neuen Typs beim Erzeugen der Klasse nicht mehr durch eine eingehüllte Fassung ersetzt, sofern die Unterklasse sie nicht ausdrücklich überschreibt. (Beigetragen von Tomasz Pytel in gh-132284.)

Integrierte Objekte

Befehlszeile und Umgebung

  • Der Schalter für die Importzeit kann jetzt über das neue -X importtime=2 auch Module erfassen, die bereits geladen sind („cached“). Wird ein solches Modul importiert, werden die Zeiten self und cumulative durch die Zeichenkette cached ersetzt.

    Werte über 2 für -X importtime sind jetzt für die künftige Verwendung vorbehalten.

    (Beigetragen von Noah Kim und Adam Turner in gh-118655.)

  • Die Befehlszeilenoption -c entfernt vor der Ausführung jetzt selbsttätig die Einrückung ihres Code-Arguments. (Beigetragen von Jon Crall und Steven Sun in gh-103998.)

  • -J ist nicht länger ein für Jython vorbehaltener Schalter und hat jetzt keine besondere Bedeutung mehr. (Beigetragen von Adam Turner in gh-133336.)

PEP 758: except- und except*-Ausdrücke ohne Klammern erlauben

Bei den Ausdrücken except und except* dürfen die Klammern jetzt wegfallen, wenn mehrere Ausnahmetypen angegeben sind und die as-Klausel nicht verwendet wird. Zum Beispiel:

try:
    connect_to_server()
except TimeoutError, ConnectionRefusedError:
    print('The network has ceased to be!')

(Beigetragen von Pablo Galindo und Brett Cannon in PEP 758 und gh-131831.)

PEP 765: Ablaufsteuerung in finally-Blöcken

Der Compiler gibt jetzt eine SyntaxWarning aus, wenn eine Anweisung return, break oder continue dazu führt, dass ein finally-Block verlassen wird. Diese Änderung ist in PEP 765 festgelegt.

Ist diese Änderung in bestimmten Lagen unbequem (etwa weil die Warnungen durch einen Linter ohnehin doppelt kommen), lassen sich mit dem Warnungsfilter alle Syntaxwarnungen abschalten, indem ignore::SyntaxWarning als Filter ergänzt wird. Das lässt sich mit einem Filter verbinden, der andere Warnungen in Fehler umwandelt (etwa indem -Werror -Wignore::SyntaxWarning als Befehlszeilenoptionen übergeben oder PYTHONWARNINGS=error,ignore::SyntaxWarning gesetzt wird).

Beachte, dass ein solcher Filter, zur Laufzeit über das Modul warnings gesetzt, die Warnung nur in Code unterdrückt, der nach dem Anpassen des Filters übersetzt wird. Code, der vor dem Anpassen übersetzt wurde (etwa beim Importieren eines Moduls), gibt die Syntaxwarnung weiterhin aus.

(Beigetragen von Irit Katriel in gh-130080.)

Speicherbereinigung

Ab Python 3.14.5:

Die Speicherbereinigung (Garbage Collector, GC) hat sich in Python 3.14.5 geändert.

Python 3.14.0 bis 3.14.4 wurden mit einer neuen inkrementellen Speicherbereinigung ausgeliefert. Wegen einer Reihe von Meldungen über erheblichen Speicherdruck in Produktivumgebungen wurde sie jedoch auf die generationsbasierte Speicherbereinigung aus 3.13 zurückgenommen. Diese wird in Python 3.14.5 und neuer verwendet.

Vorher in Python 3.14.0 bis 3.14.4:

Die Speicherbereinigung für Zyklen arbeitet jetzt inkrementell. Das bedeutet, dass die maximalen Pausenzeiten bei größeren Heaps um eine Größenordnung oder mehr sinken.

Es gibt jetzt nur noch zwei Generationen: jung und alt. Wird gc.collect() nicht unmittelbar aufgerufen, läuft die Speicherbereinigung etwas seltener. Läuft sie, bereinigt sie die junge Generation und ein Inkrement der alten Generation, statt eine oder mehrere Generationen vollständig zu bereinigen.

Das Verhalten von gc.collect() ändert sich leicht:

  • gc.collect(1): Führt ein Inkrement der Speicherbereinigung aus, statt Generation 1 zu bereinigen.

  • Andere Aufrufe von gc.collect() sind unverändert.

(Beigetragen von Mark Shannon in gh-108362.)

Interaktive Standard-Shell

  • Die interaktive Standard-Shell hebt jetzt die Python-Syntax hervor. Das Feature ist standardmäßig eingeschaltet, außer wenn PYTHON_BASIC_REPL oder eine andere Umgebungsvariable gesetzt ist, die Farbe abschaltet. Näheres unter Farbsteuerung.

    Das Standardfarbschema für die Syntaxhervorhebung ist auf guten Kontrast ausgelegt und verwendet für größtmögliche Verträglichkeit ausschließlich die 4-Bit-ANSI-Farbcodes des VGA-Standards. Das Schema lässt sich über die experimentelle API _colorize.set_theme() anpassen. Diese kann interaktiv oder im Skript PYTHONSTARTUP aufgerufen werden. Beachte, dass diese Funktion keine Stabilitätsgarantien hat und sich ändern oder wegfallen kann.

    (Beigetragen von Łukasz Langa in gh-131507.)

  • Die interaktive Standard-Shell unterstützt jetzt die automatische Vervollständigung von Importen. Tippst du import co und drückst <Tab>, werden also Module vorgeschlagen, die mit co beginnen. Ebenso schlägt from concurrent import i Untermodule von concurrent vor, die mit i beginnen. Beachte, dass die automatische Vervollständigung von Modulattributen derzeit nicht unterstützt wird. (Beigetragen von Tomas Roun in gh-69605.)

Neue Module

  • annotationlib: Zum Untersuchen von Annotationen. Näheres unter PEP 749. (Beigetragen von Jelle Zijlstra in gh-119180.)

  • compression (einschließlich compression.zstd): Ein Paket für Module rund um die Kompression, darunter ein neues Modul zur Unterstützung des Kompressionsformats Zstandard. Näheres unter PEP 784. (Beigetragen von Emma Harper Smith, Adam Turner, Gregory P. Smith, Tomas Roun, Victor Stinner und Rogdham in gh-132983.)

  • concurrent.interpreters: Unterstützung für mehrere Interpreter in der Standardbibliothek. Näheres unter PEP 734. (Beigetragen von Eric Snow in gh-134939.)

  • string.templatelib: Unterstützung für Template-String-Literale (t-Strings). Näheres unter PEP 750. (Beigetragen von Jim Baker, Guido van Rossum, Paul Everitt, Koudai Aono, Lysandros Nikolaou, Dave Peck, Adam Turner, Jelle Zijlstra, Bénédikt Tran und Pablo Galindo Salgado in gh-132661.)

Verbesserte Module

argparse

  • Der Standardwert des Programmnamens für argparse.ArgumentParser spiegelt jetzt wider, auf welchem Weg der Python-Interpreter den Code des Moduls __main__ finden sollte. (Beigetragen von Serhiy Storchaka und Alyssa Coghlan in gh-66436.)

  • Der optionale Parameter suggest_on_error ist für argparse.ArgumentParser hinzugekommen. Er schaltet Vorschläge für Argumentauswahlen und Namen von Unterparsern ein, wenn der Benutzer sich vertippt. (Beigetragen von Savannah Ostrowski in gh-124456.)

  • Farbe für den Hilfetext ist eingeschaltet. Sie lässt sich über den optionalen Parameter color von argparse.ArgumentParser abschalten. Steuern lässt sie sich außerdem über Umgebungsvariablen. (Beigetragen von Hugo van Kemenade in gh-130645.)

ast

  • compare() ist hinzugekommen, eine Funktion zum Vergleichen zweier ASTs. (Beigetragen von Batuhan Taskaya und Jeremy Hylton in gh-60191.)

  • Unterstützung für copy.replace() bei AST-Knoten ist hinzugekommen. (Beigetragen von Bénédikt Tran in gh-121141.)

  • Docstrings werden auf Optimierungsstufe 2 jetzt aus einem optimierten AST entfernt. (Beigetragen von Irit Katriel in gh-123958.)

  • Die Ausgabe von repr() für AST-Knoten enthält jetzt mehr Informationen. (Beigetragen von Tomas Roun in gh-116022.)

  • Wird die Funktion parse() mit einem AST als Eingabe aufgerufen, prüft sie jetzt immer, ob der Typ des Wurzelknotens passt. (Beigetragen von Irit Katriel in gh-130139.)

  • Neue Optionen für die Befehlszeilenschnittstelle sind hinzugekommen: --feature-version, --optimize und --show-empty. (Beigetragen von Semyon Moroz in gh-133367.)

asyncio

Kalender

concurrent.futures

  • Eine neue Executor-Klasse InterpreterPoolExecutor ist hinzugekommen, die mehrere Python-Interpreter im selben Prozess („Subinterpreter“) für Python-Code zugänglich macht. Sie verwendet einen Vorrat unabhängiger Python-Interpreter, um Aufrufe asynchron auszuführen.

    Das ist getrennt von dem neuen Modul interpreters, das PEP 734 einführt. (Beigetragen von Eric Snow in gh-124548.)

  • Auf Unix-Plattformen außer macOS ist „forkserver“ jetzt die Standard-Startmethode für ProcessPoolExecutor (anstelle von „fork“). Diese Änderung betrifft Windows und macOS nicht. Dort bleibt „spawn“ die Standard-Startmethode.

    Brauchst du die mit Threads unverträgliche Methode fork, musst du sie ausdrücklich anfordern, indem du ProcessPoolExecutor einen multiprocessing-Kontext mp_context übergibst.

    Unter Einschränkungen von forkserver stehen Informationen und Unterschiede zur Methode fork und dazu, wie diese Änderung bestehenden Code mit veränderbaren globalen gemeinsamen Variablen und/oder gemeinsamen Objekten betreffen kann, die sich nicht selbsttätig picklen lassen.

    (Beigetragen von Gregory P. Smith in gh-84559.)

  • Zwei neue Methoden sind für ProcessPoolExecutor hinzugekommen, terminate_workers() und kill_workers(), um alle lebenden Arbeiterprozesse im angegebenen Vorrat zu beenden oder abzuschießen. (Beigetragen von Charles Machalow in gh-130849.)

  • Der optionale Parameter buffersize ist für Executor.map hinzugekommen, um die Anzahl der eingereichten Aufträge zu begrenzen, deren Ergebnisse noch nicht geliefert wurden. Ist der Puffer voll, hält die Iteration über die iterables an, bis ein Ergebnis aus dem Puffer geliefert wird. (Beigetragen von Enzo Bonnal und Josh Rosenberg in gh-74028.)

configparser

  • configparser schreibt aus Sicherheitsgründen keine Konfigurationsdateien mehr, die es nicht lesen kann. Der Versuch, mit write() Schlüssel zu schreiben, die Trennzeichen enthalten oder mit dem Muster einer Abschnittsüberschrift beginnen, löst einen InvalidWriteError aus. (Beigetragen von Jacob Lincoln in gh-129270.)

contextvars

ctypes

  • Die Anordnung von Bitfeldern in Structure- und Union-Objekten entspricht jetzt eher den Vorgaben der Plattform (GCC/Clang oder MSVC). Insbesondere überlappen sich Felder nicht mehr. (Beigetragen von Matthias Görgens in gh-97702.)

  • Das Klassenattribut Structure._layout_ lässt sich jetzt setzen, um eine abweichende ABI zu treffen. (Beigetragen von Petr Viktorin in gh-97702.)

  • Die Klasse der Felddeskriptoren von Structure und Union ist jetzt als CField verfügbar und hat neue Attribute, die bei Fehlersuche und Introspektion helfen. (Beigetragen von Petr Viktorin in gh-128715.)

  • Unter Windows ist die Ausnahme COMError jetzt öffentlich. (Beigetragen von Jun Komoda in gh-126686.)

  • Unter Windows ist die Funktion CopyComPointer() jetzt öffentlich. (Beigetragen von Jun Komoda in gh-127275.)

  • memoryview_at() ist hinzugekommen, eine Funktion, die ein memoryview-Objekt erzeugt, das auf den übergebenen Zeiger und die übergebene Länge verweist. Sie arbeitet wie ctypes.string_at(), vermeidet aber eine Kopie des Puffers, und ist typischerweise nützlich, wenn man reine Python-Rückruffunktionen umsetzt, denen Puffer mit dynamischer Größe übergeben werden. (Beigetragen von Rian Hunter in gh-112018.)

  • Die komplexen Typen c_float_complex, c_double_complex und c_longdouble_complex sind jetzt verfügbar, wenn sowohl der Compiler als auch die Bibliothek libffi komplexe C-Typen unterstützen. (Beigetragen von Sergey B Kirpichev in gh-61103.)

  • ctypes.util.dllist() ist hinzugekommen, um die vom aktuellen Prozess geladenen gemeinsamen Bibliotheken aufzulisten. (Beigetragen von Brian Ward in gh-119349.)

  • Der Zwischenspeicher für ctypes.POINTER()-Typen ist von einem globalen internen Zwischenspeicher (_pointer_type_cache) in das Attribut _CData.__pointer_type__ der entsprechenden ctypes-Typen umgezogen. Damit wächst der Zwischenspeicher in manchen Lagen nicht mehr unbegrenzt. (Beigetragen von Sergey Miryanov in gh-100926.)

  • Der Typ py_object unterstützt jetzt die Indizierung und ist damit ein generischer Typ. (Beigetragen von Brian Schubert in gh-132168.)

  • ctypes unterstützt jetzt Free-Threading-Builds. (Beigetragen von Kumar Aditya und Peter Bierma in gh-127945.)

curses

datetime

decimal

  • Decimal.from_number() ist als alternativer Konstruktor für Decimal hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-121798.)

  • IEEEContext() ist jetzt zugänglich, um Kontexte zu erzeugen, die den Dezimal-Austauschformaten von IEEE 754 (2008) entsprechen. (Beigetragen von Sergey B Kirpichev in gh-53032.)

difflib

  • Vergleichsseiten mit hervorgehobenen Änderungen, die die Klasse HtmlDiff erzeugt, unterstützen jetzt den „Dunkelmodus“. (Beigetragen von Jiahao Li in gh-129939.)

dis

errno

  • Die Konstante für den Fehlercode EHWPOISON ist hinzugekommen. (Beigetragen von James Roy in gh-126585.)

faulthandler

fnmatch

  • filterfalse() ist hinzugekommen, eine Funktion, die Namen zurückweist, die auf ein angegebenes Muster passen. (Beigetragen von Bénédikt Tran in gh-74598.)

fractions

  • Ein Fraction-Objekt lässt sich jetzt aus jedem Objekt erzeugen, das die Methode as_integer_ratio() hat. (Beigetragen von Serhiy Storchaka in gh-82017.)

  • Fraction.from_number() ist als alternativer Konstruktor für Fraction hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-121797.)

functools

  • Der Wächter Placeholder ist hinzugekommen. Er lässt sich mit den Funktionen partial() oder partialmethod() verwenden, um im zurückgegebenen partial-Objekt einen Platz für positionsbezogene Argumente freizuhalten. (Beigetragen von Dominykas Grigonis in gh-119127.)

  • Der Parameter initial von reduce() darf jetzt als Schlüsselwortargument übergeben werden. (Beigetragen von Sayandip Dutta in gh-125916.)

getopt

  • Unterstützung für Optionen mit optionalen Argumenten ist hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-126374.)

  • Unterstützung dafür, vermischte Optionen und Nicht-Options-Argumente in der ursprünglichen Reihenfolge zurückzugeben, ist hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-126390.)

getpass

  • Tastaturrückmeldung wird in der Funktion getpass() über das optionale, nur über Schlüsselwort angebbare Argument echo_char unterstützt. Bei jeder Zeicheneingabe werden Platzhalterzeichen dargestellt und beim Löschen eines Zeichens wieder entfernt. (Beigetragen von Semyon Moroz in gh-77065.)

graphlib

heapq

hmac

  • Eine integrierte Umsetzung von HMAC (RFC 2104) ist hinzugekommen, die formal verifizierten Code aus dem Projekt HACL* verwendet. Diese Umsetzung dient als Rückfallebene, wenn die HMAC-Umsetzung von OpenSSL nicht verfügbar ist. (Beigetragen von Bénédikt Tran in gh-99108.)

http

  • Verzeichnisauflistungen und Fehlerseiten, die das Modul http.server erzeugt, erlauben dem Browser, seinen eigenen Dunkelmodus anzuwenden. (Beigetragen von Yorik Hansen in gh-123430.)

  • Das Modul http.server unterstützt mit der Klasse http.server.HTTPSServer jetzt das Ausliefern über HTTPS. Diese Funktionalität ist über die Befehlszeilenschnittstelle (python -m http.server) mit den folgenden Optionen zugänglich:

    (Beigetragen von Semyon Moroz in gh-85162.)

imaplib

inspect

  • signature() nimmt ein neues Argument annotation_format, um das für die Darstellung von Annotationen verwendete annotationlib.Format zu steuern. (Beigetragen von Jelle Zijlstra in gh-101552.)

  • Signature.format() nimmt ein neues Argument unquote_annotations. Ist es wahr, werden Annotationen in Zeichenkettenform ohne umgebende Anführungszeichen angezeigt. (Beigetragen von Jelle Zijlstra in gh-101552.)

  • Die Funktion ispackage() ist hinzugekommen, um festzustellen, ob ein Objekt ein Paket ist. (Beigetragen von Zhikang Yan in gh-125634.)

io

  • Das Lesen von Text aus einem nicht blockierenden Strom mit read kann jetzt einen BlockingIOError auslösen, wenn die Operation nicht unmittelbar Bytes zurückgeben kann. (Beigetragen von Giovanni Siragusa in gh-109523.)

  • Die Protokolle Reader und Writer sind als einfachere Alternativen zu den Pseudo-Protokollen typing.IO, typing.TextIO und typing.BinaryIO hinzugekommen. (Beigetragen von Sebastian Rittau in gh-127648.)

json

linecache

  • getline() kann jetzt auch den Quelltext eingefrorener Module abrufen. (Beigetragen von Tian Gao in gh-131638.)

logging.handlers

math

  • Ausführlichere Fehlermeldungen bei Definitionsbereichsfehlern im Modul sind hinzugekommen. (Beigetragen von Charlie Zhao und Sergey B Kirpichev in gh-101410.)

mimetypes

  • Eine öffentliche Befehlszeilenschnittstelle für das Modul ist hinzugekommen, aufzurufen über python -m mimetypes. (Beigetragen von Oleg Iarygin und Hugo van Kemenade in gh-93096.)

  • Mehrere neue MIME-Typen auf der Grundlage von RFCs und üblicher Verwendung sind hinzugekommen:

    MIME-Typen von Microsoft und aus RFC 8081 für Schriftarten

    • Embedded OpenType: application/vnd.ms-fontobject

    • OpenType Layout (OTF) font/otf

    • TrueType: font/ttf

    • WOFF 1.0 font/woff

    • WOFF 2.0 font/woff2

    MIME-Typen aus RFC 9559 für audiovisuelle Containerstrukturen von Matroska

    • Ton ohne Bild: audio/matroska (.mka)

    • Video: video/matroska (.mkv)

    • stereoskopisches Video: video/matroska-3d (.mk3d)

    Bilder mit RFCs

    • RFC 1494: CCITT Gruppe 3 (.g3)

    • RFC 3362: Echtzeit-Faksimile, T.38 (.t38)

    • RFC 3745: JPEG 2000 (.jp2), Erweiterung (.jpx) und zusammengesetzt (.jpm)

    • RFC 3950: Tag Image File Format Fax eXtended, TIFF-FX (.tfx)

    • RFC 4047: Flexible Image Transport System (.fits)

    • RFC 7903: Enhanced Metafile (.emf) und Windows Metafile (.wmf)

    Weitere Ergänzungen und Änderungen bei MIME-Typen

    • RFC 2361: Typ für .avi auf video/vnd.avi und für .wav auf audio/vnd.wave geändert

    • RFC 4337: MPEG-4 audio/mp4 (.m4a) hinzugefügt

    • RFC 5334: Ogg-Medien (.oga, .ogg und .ogx) hinzugefügt

    • RFC 6713: gzip application/gzip (.gz) hinzugefügt

    • RFC 9639: FLAC audio/flac (.flac) hinzugefügt

    • RFC 9512: MIME-Typ application/yaml für YAML-Dateien (.yaml und .yml)

    • 7z application/x-7z-compressed (.7z) hinzugefügt

    • Android-Paket application/vnd.android.package-archive (.apk) hinzugefügt, sofern nicht streng geprüft wird

    • deb application/x-debian-package (.deb) hinzugefügt

    • glTF binär model/gltf-binary (.glb) hinzugefügt

    • glTF JSON/ASCII model/gltf+json (.gltf) hinzugefügt

    • M4V video/x-m4v (.m4v) hinzugefügt

    • PHP application/x-httpd-php (.php) hinzugefügt

    • RAR application/vnd.rar (.rar) hinzugefügt

    • RPM application/x-rpm (.rpm) hinzugefügt

    • STL model/stl (.stl) hinzugefügt

    • Windows Media Video video/x-ms-wmv (.wmv) hinzugefügt

    • De facto: WebM audio/webm (.weba) hinzugefügt

    • ECMA-376: Typen .docx, .pptx und .xlsx hinzugefügt

    • OASIS: OpenDocument-Typen .odg, .odp, .ods und .odt hinzugefügt

    • W3C: EPUB application/epub+zip (.epub) hinzugefügt

    (Beigetragen von Sahil Prajapati und Hugo van Kemenade in gh-84852, von Sasha „Nelie“ Chernykh und Hugo van Kemenade in gh-132056 und von Hugo van Kemenade in gh-89416, gh-85957 und gh-129965.)

multiprocessing

  • Auf Unix-Plattformen außer macOS ist ‚forkserver‘ jetzt die voreingestellte Startmethode (an der Stelle von ‚fork‘). Diese Änderung betrifft weder Windows noch macOS, wo ‚spawn‘ die voreingestellte Startmethode bleibt.

    Wird die mit Threads unverträgliche Methode fork benötigt, musst du sie ausdrücklich über einen Kontext von get_context() anfordern (bevorzugt) oder die Voreinstellung über set_start_method() ändern.

    Unter Einschränkungen von forkserver stehen Informationen und Unterschiede zur Methode fork und dazu, wie diese Änderung bestehenden Code mit veränderbaren globalen gemeinsamen Variablen und/oder gemeinsamen Objekten betreffen kann, die sich nicht selbsttätig picklen lassen.

    (Beigetragen von Gregory P. Smith in gh-84559.)

  • Die Startmethode 'forkserver' von multiprocessing prüft jetzt die Echtheit ihres Steuer-Sockets, damit nicht allein Dateisystemrechte darüber bestimmen, welche anderen Prozesse den Forkserver dazu bringen können, Arbeitsprozesse zu starten und Code auszuführen. (Beigetragen von Gregory P. Smith für gh-97514.)

  • Die Stellvertreterobjekte von multiprocessing für die Typen list und dict erhalten bisher übersehene, fehlende Methoden:

    • clear() und copy() für Stellvertreter von list

    • fromkeys(), reversed(d), d | {}, {} | d, d |= {'b': 2} für Stellvertreter von dict

    (Beigetragen von Roy Hyunjin Han für gh-103134.)

  • Unterstützung für gemeinsam genutzte set-Objekte über SyncManager.set() ist hinzugekommen. Die Methode set() in Manager() ist jetzt verfügbar. (Beigetragen von Mingyu Park in gh-129949.)

  • Die Methode interrupt() ist für multiprocessing.Process-Objekte hinzugekommen. Sie beendet den Kindprozess, indem sie SIGINT sendet. Damit können finally-Klauseln eine Rückverfolgung für den beendeten Prozess ausgeben. (Beigetragen von Artem Pulkin in gh-131913.)

Operator

  • is_none() und is_not_none() sind als Funktionspaar hinzugekommen, sodass operator.is_none(obj) gleichbedeutend mit obj is None und operator.is_not_none(obj) gleichbedeutend mit obj is not None ist. (Beigetragen von Raymond Hettinger und Nico Mexis in gh-115808.)

os

os.path

  • Der Parameter strict von realpath() nimmt einen neuen Wert an, ALLOW_MISSING. Wird er verwendet, werden andere Fehler als FileNotFoundError erneut ausgelöst. Der entstehende Pfad darf fehlen, ist dann aber frei von symbolischen Verweisen. (Beigetragen von Petr Viktorin für CVE 2025-4517.)

pathlib

  • Methoden sind zu pathlib.Path hinzugekommen, um Dateien und Verzeichnisse rekursiv zu kopieren oder zu verschieben:

    • copy() kopiert eine Datei oder einen Verzeichnisbaum an ein Ziel.

    • copy_into() kopiert in ein Zielverzeichnis.

    • move() verschiebt eine Datei oder einen Verzeichnisbaum an ein Ziel.

    • move_into() verschiebt in ein Zielverzeichnis.

    (Beigetragen von Barney Gale in gh-73991.)

  • Das Attribut info ist hinzugekommen. Es enthält ein Objekt, das das neue Protokoll pathlib.types.PathInfo umsetzt. Das Objekt erlaubt es, den Dateityp abzufragen, und speichert die Ergebnisse von stat() intern zwischen. Pfadobjekte, die iterdir() erzeugt, werden mit den Dateitypinformationen vorbelegt, die beim Durchsuchen des übergeordneten Verzeichnisses angefallen sind. (Beigetragen von Barney Gale in gh-125413.)

pdb

  • Das Modul pdb kann sich jetzt über die neue Befehlszeilenoption -p PID aus der Ferne an einen laufenden Python-Prozess anhängen:

    python -m pdb -p 1234

    Damit verbindet sich pdb mit dem Python-Prozess der angegebenen PID und du kannst ihn interaktiv untersuchen. Beachte, dass es in der Arbeitsweise des Python-Interpreters liegt, dass das Anhängen an einen fernen Prozess, der in einem Systemaufruf blockiert ist oder auf Ein-/Ausgabe wartet, erst dann greift, wenn die nächste Bytecode-Anweisung ausgeführt wird oder der Prozess ein Signal empfängt.

    Dieses Feature verwendet PEP 768 und die neue Funktion sys.remote_exec(), um sich an den fernen Prozess anzuhängen und die PDB-Befehle an ihn zu senden.

    (Beigetragen von Matt Wozniski und Pablo Galindo in gh-131591.)

  • Fest im Code stehende Haltepunkte (breakpoint() und set_trace()) verwenden jetzt die zuletzt verwendete Pdb-Instanz wieder, die set_trace() aufruft, statt jedes Mal eine neue zu erzeugen. Damit bleiben alle instanzbezogenen Daten wie display und commands über solche Haltepunkte hinweg erhalten. (Beigetragen von Tian Gao in gh-121450.)

  • Ein neues Argument mode ist zu pdb.Pdb hinzugekommen. Der Befehl restart ist abgeschaltet, wenn pdb im Modus inline läuft. (Beigetragen von Tian Gao in gh-123757.)

  • Es erscheint eine Rückfrage, wenn jemand versucht, pdb im Modus inline zu verlassen. y, Y, <Enter> oder EOF bestätigen das Beenden und rufen sys.exit() auf, statt bdb.BdbQuit auszulösen. (Beigetragen von Tian Gao in gh-124704.)

  • Haltepunkte im Code selbst wie breakpoint() oder pdb.set_trace() halten das Programm jetzt immer im aufrufenden Rahmen an und übergehen ein etwaiges skip-Muster. (Beigetragen von Tian Gao in gh-130493.)

  • <tab> am Zeilenanfang einer mehrzeiligen Eingabe in pdb erzeugt jetzt eine Einrückung von vier Leerzeichen, statt ein \t-Zeichen einzufügen. (Beigetragen von Tian Gao in gh-130471.)

  • Für mehrzeilige Eingaben in pdb ist eine selbsttätige Einrückung hinzugekommen. Sie behält entweder die Einrückung der letzten Zeile bei oder rückt um vier Leerzeichen ein, wenn sie einen neuen Codeblock erkennt. (Beigetragen von Tian Gao in gh-133350.)

  • $_asynctask ist hinzugekommen, um gegebenenfalls auf den aktuellen asyncio-Auftrag zuzugreifen. (Beigetragen von Tian Gao in gh-124367.)

  • pdb.set_trace_async() ist hinzugekommen, um asyncio-Coroutinen untersuchen zu können. Mit dieser Funktion sind await-Anweisungen möglich. (Beigetragen von Tian Gao in gh-132576.)

  • In pdb angezeigter Quelltext wird mit Syntaxhervorhebung dargestellt. Dieses Feature lässt sich mit denselben Mitteln steuern wie bei der voreingestellten interaktiven Shell, zusätzlich über das neu hinzugekommene Argument colorize von pdb.Pdb. (Beigetragen von Tian Gao und Łukasz Langa in gh-133355.)

pickle

  • Die voreingestellte Protokollversion des Moduls pickle steht jetzt auf 5. Näheres unter Pickle-Protokolle.

  • Ausnahmehinweise für Fehler bei der Pickle-Serialisierung sind hinzugekommen. Sie erlauben es, die Quelle des Fehlers zu bestimmen. (Beigetragen von Serhiy Storchaka in gh-122213.)

platform

  • invalidate_caches() ist hinzugekommen, eine Funktion, die zwischengespeicherte Ergebnisse im Modul platform verwirft. (Beigetragen von Bénédikt Tran in gh-122549.)

pydoc

  • Annotationen in der Hilfeausgabe werden jetzt meist in einer Form dargestellt, die dem ursprünglichen Quelltext näherkommt. (Beigetragen von Jelle Zijlstra in gh-101552.)

re

  • \z wird in regulären Ausdrücken als Gleichbedeutung für \Z unterstützt. Viele andere Engines für reguläre Ausdrücke legen es eindeutig aus, anders als \Z, das sich in Feinheiten anders verhält. (Beigetragen von Serhiy Storchaka in gh-133306.)

  • \B in regulären Ausdrücken passt jetzt auch auf die leere Eingabezeichenkette und ist damit immer das Gegenstück zu \b. (Beigetragen von Serhiy Storchaka in gh-124130.)

socket

  • Die Unterstützung für Bluetooth-Sockets ist verbessert und ausgebessert.

    • Die Unterstützung für Bluetooth-Sockets unter NetBSD und DragonFly BSD ist ausgebessert. (Beigetragen von Serhiy Storchaka in gh-132429.)

    • Die Unterstützung für BTPROTO_HCI unter FreeBSD ist ausgebessert. (Beigetragen von Victor Stinner in gh-111178.)

    • Unterstützung für BTPROTO_SCO unter FreeBSD ist hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-85302.)

    • Unterstützung für cid und bdaddr_type in der Adresse für BTPROTO_L2CAP unter FreeBSD ist hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-132429.)

    • Unterstützung für channel in der Adresse für BTPROTO_HCI unter Linux ist hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-70145.)

    • Unter Linux wird eine ganze Zahl als Adresse für BTPROTO_HCI angenommen. (Beigetragen von Serhiy Storchaka in gh-132099.)

    • cid wird in getsockname() für BTPROTO_L2CAP zurückgegeben. (Beigetragen von Serhiy Storchaka in gh-132429.)

    • Viele neue Konstanten sind hinzugekommen. (Beigetragen von Serhiy Storchaka in gh-132734.)

ssl

  • Über den booleschen Wert HAS_PHA wird angezeigt, ob das Modul ssl die Client-Authentifizierung nach dem Handshake (PHA) von TLSv1.3 unterstützt. (Beigetragen von Will Childs-Klein in gh-128036.)

struct

  • Die C-Typen float complex und double complex werden im Modul struct unterstützt (Formatzeichen 'F' beziehungsweise 'D'). (Beigetragen von Sergey B Kirpichev in gh-121249.)

symtable

sys

  • Die bisher nicht dokumentierte besondere Funktion sys.getobjects(), die es nur in besonderen Builds von Python gibt, darf jetzt auch Objekte aus anderen Interpretern zurückgeben als aus dem, in dem sie aufgerufen wird. (Beigetragen von Eric Snow in gh-125286.)

  • sys._is_immortal() ist hinzugekommen, um festzustellen, ob ein Objekt unsterblich ist. (Beigetragen von Peter Bierma in gh-128509.)

  • Unter FreeBSD enthält sys.platform die Hauptversionsnummer nicht mehr. Der Wert ist jetzt immer 'freebsd' statt 'freebsd13' oder 'freebsd14'. (Beigetragen von Michael Osipov in gh-129393.)

  • sys._clear_type_cache() löst eine DeprecationWarning aus. Diese Funktion wurde in Python 3.13 als veraltet markiert, löste aber keine Warnung zur Laufzeit aus.

  • sys.remote_exec() ist hinzugekommen, um die neue Schnittstelle für externe Debugger umzusetzen. Einzelheiten unter PEP 768. (Beigetragen von Pablo Galindo Salgado, Matt Wozniski und Ivona Stojanovic in gh-131591.)

  • Der Namensraum sys._jit ist hinzugekommen. Er enthält Hilfsmittel, um die Just-in-time-Kompilierung zu untersuchen. (Beigetragen von Brandt Bucher in gh-133231.)

sys.monitoring

  • Zwei neue Überwachungsereignisse sind hinzugekommen, BRANCH_LEFT und BRANCH_RIGHT. Sie ersetzen das Ereignis BRANCH, das damit als veraltet markiert ist. (Beigetragen von Mark Shannon in gh-122548.)

  • sys.monitoring.clear_tool_id() ist hinzugekommen, um alle Ereignisse und Rückruffunktionen abzumelden, die zu einer Werkzeugkennung gehören. sys.monitoring.free_tool_id() ruft sie jetzt auf, bevor die Werkzeugkennung freigegeben wird, statt deren Ereignisse und Rückruffunktionen angemeldet zu lassen. (Beigetragen von Tian Gao in gh-116750.)

sysconfig

tarfile

threading

tkinter

  • Die tkinter-Widget-Methoden after() und after_idle() nehmen jetzt Schlüsselwortargumente an. (Beigetragen von Zhikang Yan in gh-126899.)

  • Für tkinter.OptionMenu und tkinter.ttk.OptionMenu lässt sich jetzt ein Name angeben. (Beigetragen von Zhikang Yan in gh-130482.)

turtle

types

typing

  • Die Typen types.UnionType und typing.Union sind jetzt andere Namen füreinander, das heißt, Vereinigungen in der alten Schreibweise (erzeugt mit Union[int, str]) und in der neuen Schreibweise (int | str) erzeugen jetzt beide Instanzen desselben Laufzeittyps. Damit verhalten sich die beiden Schreibweisen gleich, es ergeben sich aber einige Verhaltensunterschiede, die alle betreffen können, die Typen zur Laufzeit untersuchen:

    • Beide Schreibweisen zum Erzeugen einer Vereinigung ergeben in repr() jetzt dieselbe Zeichenkettendarstellung. repr(Union[int, str]) ist zum Beispiel jetzt "int | str" statt "typing.Union[int, str]".

    • Vereinigungen, die mit der alten Schreibweise erzeugt werden, werden nicht mehr zwischengespeichert. Vorher gab Union[int, str] bei mehrfacher Ausführung dasselbe Objekt zurück (Union[int, str] is Union[int, str] war True), jetzt kommen zwei verschiedene Objekte heraus. Verwende ==, um Vereinigungen auf Gleichheit zu prüfen, nicht is. Vereinigungen in der neuen Schreibweise wurden nie auf diese Weise zwischengespeichert. Diese Änderung kann den Speicherverbrauch von Programmen erhöhen, die sehr viele Vereinigungen durch Indizierung von typing.Union erzeugen. Mehrere Umstände wiegen diese Kosten allerdings auf: Annotationen werden in Python 3.14 wegen PEP 649 standardmäßig nicht mehr ausgewertet. Eine Instanz von types.UnionType ist selbst deutlich kleiner als das Objekt, das Union[] in früheren Python-Versionen zurückgab, und der entfallene Zwischenspeicher spart ebenfalls Platz. Daher ist es unwahrscheinlich, dass diese Änderung bei den meisten Anwendern zu einem merklich höheren Speicherverbrauch führt.

    • Vorher waren Vereinigungen in der alten Schreibweise über die private Klasse typing._UnionGenericAlias umgesetzt. Diese Klasse wird für die Umsetzung nicht mehr gebraucht, ist aber aus Gründen der Rückwärtsverträglichkeit erhalten geblieben. Ihre Entfernung ist für Python 3.17 geplant. Verwende besser die dokumentierten Hilfsmittel zur Introspektion wie get_origin() und typing.get_args(), statt dich auf private Umsetzungsdetails zu verlassen.

    • typing.Union selbst lässt sich jetzt in Prüfungen mit isinstance() verwenden. isinstance(int | str, typing.Union) gibt zum Beispiel True zurück. Vorher löste das einen TypeError aus.

    • Das Attribut __args__ von typing.Union-Objekten ist nicht mehr beschreibbar.

    • An Union-Objekten lassen sich überhaupt keine Attribute mehr setzen. In früheren Versionen funktionierte das nur bei Dunder-Attributen, war nie als funktionierend dokumentiert und in vielen Fällen auf feine Weise fehlerhaft.

    (Beigetragen von Jelle Zijlstra in gh-105499.)

  • TypeAliasType unterstützt jetzt das Entpacken mit Stern.

unicodedata

  • Die Unicode-Datenbank ist auf Unicode 16.0.0 aktualisiert.

unittest

urllib

  • Der Algorithmus zur HTTP-Digest-Authentifizierung in urllib.request ist auf einen neueren Stand gebracht: SHA-256-Digest-Authentifizierung nach RFC 7616 wird unterstützt. (Beigetragen von Calvin Bui in gh-128193.)

  • Handhabung und Normkonformität beim Auswerten und Erzeugen von file:-URLs sind verbessert.

    In url2pathname():

    • Eine vollständige URL wird angenommen, wenn das neue Argument require_scheme wahr ist.

    • Die URL-Autorität wird verworfen, wenn sie dem lokalen Rechnernamen entspricht.

    • Die URL-Autorität wird verworfen, wenn sie zu einer lokalen IP-Adresse aufgelöst wird und das neue Argument resolve_host wahr ist.

    • Abfrage- und Fragmentteil der URL werden verworfen.

    • URLError wird ausgelöst, wenn eine URL-Autorität nicht lokal ist – außer unter Windows, wo wie bisher ein UNC-Pfad zurückgegeben wird.

    In pathname2url():

    • Eine vollständige URL wird zurückgegeben, wenn das neue Argument add_scheme wahr ist.

    • Eine leere URL-Autorität wird aufgenommen, wenn ein Pfad mit einem Schrägstrich beginnt. Der Pfad /etc/hosts wird zum Beispiel in die URL ///etc/hosts umgewandelt.

    Unter Windows werden Laufwerksbuchstaben nicht mehr in Großbuchstaben umgewandelt, und :-Zeichen, die nicht auf einen Laufwerksbuchstaben folgen, lösen keine OSError-Ausnahme mehr aus.

    (Beigetragen von Barney Gale in gh-125866.)

uuid

  • Unterstützung für die UUID-Versionen 6, 7 und 8 ist über uuid6(), uuid7() beziehungsweise uuid8() hinzugekommen, wie in RFC 9562 festgelegt. (Beigetragen von Bénédikt Tran in gh-89083.)

  • NIL und MAX sind jetzt verfügbar, um die UUID-Formate Nil und Max darzustellen, wie RFC 9562 sie festlegt. (Beigetragen von Nick Pope in gh-128427.)

  • Über python -m uuid --count lassen sich auf der Befehlszeile jetzt mehrere UUIDs auf einmal erzeugen. (Beigetragen von Simon Legner in gh-131236.)

webbrowser

  • Namen in der Umgebungsvariablen BROWSER dürfen sich jetzt auf bereits angemeldete Browser des Moduls webbrowser beziehen, statt immer einen neuen Browser-Befehl zu erzeugen.

    Damit lässt sich BROWSER unter macOS auf den Wert eines der unterstützten Browser setzen.

zipfile

Optimierungen

asyncio

  • Die Ergebnisse der Standard-Vergleichsmessungen sind um 10 bis 20 % besser geworden, nachdem für native Aufträge eine neue, doppelt verkettete Liste je Thread umgesetzt wurde, die zugleich den Speicherverbrauch senkt. Damit können externe Werkzeuge zur Introspektion wie python -m asyncio pstree den Aufrufgraphen der asyncio-Aufträge aller Threads untersuchen. (Beigetragen von Kumar Aditya in gh-107803.)

  • Das Modul unterstützt Free-Threading-Builds jetzt vollwertig. Damit lassen sich mehrere Ereignisschleifen in verschiedenen Threads parallel ausführen, mit linearer Skalierung über die Anzahl der Threads. (Beigetragen von Kumar Aditya in gh-128002.)

base64

  • b16decode() ist jetzt bis zu sechsmal schneller. (Beigetragen von Bénédikt Tran, Chris Markiewicz und Adam Turner in gh-118761.)

bdb

  • Der einfache Debugger hat jetzt ein Backend auf der Grundlage von sys.monitoring, das sich auswählen lässt, indem man dem neuen Parameter backend der Klasse Bdb den Wert 'monitoring' übergibt. (Beigetragen von Tian Gao in gh-124533.)

difflib

  • Die Funktion IS_LINE_JUNK() ist jetzt bis zu doppelt so schnell. (Beigetragen von Adam Turner und Semyon Moroz in gh-130167.)

gc

  • Ab Python 3.14.5:

    Python 3.14.0 bis 3.14.4 wurden mit einer neuen inkrementellen Speicherbereinigung ausgeliefert. Wegen einer Reihe von Meldungen über erheblichen Speicherdruck in Produktivumgebungen wurde allerdings auf die generationsbasierte Speicherbereinigung aus 3.13 zurückgegangen. Diese Speicherbereinigung wird jetzt in Python 3.14.5 und später verwendet.

  • Vorher in Python 3.14.0 bis 3.14.4:

    Die neue inkrementelle Speicherbereinigung bedeutet, dass die maximalen Pausenzeiten bei größeren Heaps um eine Größenordnung oder mehr sinken.

    Wegen dieser Optimierung hat sich die Bedeutung der Ergebnisse von get_threshold() und set_threshold() geändert, ebenso die von get_count() und get_stats().

    • Aus Gründen der Rückwärtsverträglichkeit gibt get_threshold() weiterhin ein Tupel mit drei Einträgen zurück. Der erste Wert ist wie bisher der Schwellwert für Durchläufe der jungen Generation. Der zweite Wert bestimmt, wie schnell die alte Generation durchsucht wird (die Voreinstellung ist 10, und höhere Werte bedeuten, dass die alte Generation langsamer durchsucht wird). Der dritte Wert ist jetzt bedeutungslos und immer null.

    • set_threshold() übergeht jetzt alle Einträge ab dem dritten.

    • get_count() und get_stats() geben die Ergebnisse weiterhin im selben Format zurück. Der einzige Unterschied ist, dass sich die Ergebnisse nicht mehr auf die junge, die alternde und die alte Generation beziehen, sondern auf die junge Generation sowie auf den alternden und den sammelnden Bereich der alten Generation.

    Zusammengefasst: Code, der versucht hat, das Verhalten der Zyklen-Speicherbereinigung zu beeinflussen, arbeitet unter Umständen nicht mehr genau wie beabsichtigt, ist aber sehr wahrscheinlich nicht schädlich. Jeder andere Code funktioniert einwandfrei.

    (Beigetragen von Mark Shannon in gh-108362.)

io

  • Dateien zu öffnen und zu lesen braucht jetzt weniger Systemaufrufe. Eine kleine, vom Betriebssystem zwischengespeicherte Datei vollständig zu lesen ist bis zu 15 % schneller. (Beigetragen von Cody Maloney und Victor Stinner in gh-120754 und gh-90102.)

pathlib

  • Path.read_bytes öffnet Dateien jetzt ohne Pufferung, was ein vollständiges Lesen um 9 bis 17 % beschleunigt. (Beigetragen von Cody Maloney in gh-120754.)

pdb

textwrap

  • Die Funktion dedent() ist optimiert und im Mittel um das 2,4-Fache schneller, bei größeren Eingaben noch deutlicher. Außerdem ist ein Fehler behoben, durch den Leerzeilen mit anderen Leerraumzeichen als Leerzeichen und Tabulator nur unvollständig vereinheitlicht wurden.

uuid

  • uuid3() und uuid5() sind jetzt beide bei Namen von 16 Byte etwa 40 % und bei Namen von 1024 Byte etwa 20 % schneller. Bei längeren Namen bleibt die Geschwindigkeit unverändert. (Beigetragen von Bénédikt Tran in gh-128150.)

  • uuid4() ist jetzt etwa 30 % schneller. (Beigetragen von Bénédikt Tran in gh-128150.)

zlib

  • Unter Windows wird in den voreingestellten Binärpaketen jetzt zlib-ng als Umsetzung des Moduls zlib verwendet. Es sind keine Unverträglichkeiten zwischen zlib-ng und der vorher verwendeten zlib-Umsetzung bekannt. Daraus sollte sich auf allen Kompressionsstufen eine bessere Geschwindigkeit ergeben.

    Erwähnt sei, dass zlib.Z_BEST_SPEED (1) deutlich weniger Kompression erreichen kann als die vorherige Umsetzung, dabei aber auch die Zeit für das Komprimieren deutlich verkürzt.

    (Beigetragen von Steve Dower in gh-91349.)

Entfernt

argparse

  • Die Parameter type, choices und metavar von BooleanOptionalAction sind entfernt. Sie waren seit Python 3.12 als veraltet markiert. (Beigetragen von Nikita Sobolev in gh-118805.)

  • add_argument_group() auf einer Argumentgruppe aufzurufen löst jetzt einen ValueError aus. Ebenso lösen add_argument_group() und add_mutually_exclusive_group() auf einer gegenseitig ausschließenden Gruppe jetzt beide ValueErrors aus. Dieses Verschachteln wurde nie unterstützt, funktionierte oft nicht richtig und war nur durch Vererbung unbeabsichtigt zugänglich. Diese Funktionalität war seit Python 3.11 als veraltet markiert. (Beigetragen von Savannah Ostrowski in gh-127186.)

ast

  • Die folgenden Klassen sind entfernt. Sie waren seit Python 3.8 als veraltet markierte andere Namen für Constant und gaben seit Python 3.12 Warnungen über die Abkündigung aus:

    • Bytes

    • Ellipsis

    • NameConstant

    • Num

    • Str

    Weil diese Klassen entfernt sind, werden selbst definierte Methoden visit_Num, visit_Str, visit_Bytes, visit_NameConstant und visit_Ellipsis an eigenen Unterklassen von NodeVisitor nicht mehr aufgerufen, wenn die NodeVisitor-Unterklasse einen AST besucht. Definiere stattdessen eine Methode visit_Constant.

    (Beigetragen von Alex Waygood in gh-119562.)

  • Die folgenden als veraltet markierten Eigenschaften von ast.Constant sind entfernt. Sie waren aus Verträglichkeit mit den nun entfernten AST-Klassen vorhanden:

    • Constant.n

    • Constant.s

    Verwende stattdessen Constant.value. (Beigetragen von Alex Waygood in gh-119562.)

asyncio

  • Die folgenden Klassen, Methoden und Funktionen sind entfernt. Sie waren seit Python 3.12 als veraltet markiert:

    • AbstractChildWatcher

    • FastChildWatcher

    • MultiLoopChildWatcher

    • PidfdChildWatcher

    • SafeChildWatcher

    • ThreadedChildWatcher

    • AbstractEventLoopPolicy.get_child_watcher()

    • AbstractEventLoopPolicy.set_child_watcher()

    • get_child_watcher()

    • set_child_watcher()

    (Beigetragen von Kumar Aditya in gh-120804.)

  • asyncio.get_event_loop() löst jetzt einen RuntimeError aus, wenn es keine aktuelle Ereignisschleife gibt, und erzeugt nicht mehr stillschweigend eine.

    (Beigetragen von Kumar Aditya in gh-126353.)

    Es gibt einige Muster, die asyncio.get_event_loop() verwenden. Die meisten lassen sich durch asyncio.run() ersetzen.

    Wenn du eine asynchrone Funktion ausführst, verwende einfach asyncio.run().

    Vorher:

    async def main():
    ...


loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(main())
finally:
    loop.close()

    Nachher:

    async def main():
    ...

asyncio.run(main())

    Wenn du etwas starten musst, zum Beispiel einen Server, der an einem Socket lauscht, und das dann dauerhaft laufen lassen willst, verwende asyncio.run() und ein asyncio.Event.

    Vorher:

    def start_server(loop): ...

loop = asyncio.get_event_loop()
try:
    start_server(loop)
    loop.run_forever()
finally:
    loop.close()

    Nachher:

    def start_server(loop): ...

async def main():
    start_server(asyncio.get_running_loop())
    await asyncio.Event().wait()

asyncio.run(main())

    Wenn du etwas in einer Ereignisschleife ausführen und darum herum blockierenden Code laufen lassen musst, verwende asyncio.Runner.

    Vorher:

    async def operation_one(): ...
def blocking_code(): ...
async def operation_two(): ...

loop = asyncio.get_event_loop()
try:
    loop.run_until_complete(operation_one())
    blocking_code()
    loop.run_until_complete(operation_two())
finally:
    loop.close()

    Nachher:

    async def operation_one(): ...
def blocking_code(): ...
async def operation_two(): ...

with asyncio.Runner() as runner:
    runner.run(operation_one())
    blocking_code()
    runner.run(operation_two())

email

  • Der Parameter isdst von email.utils.localtime() ist entfernt. Er war seit Python 3.12 als veraltet markiert und wurde seitdem übergangen. (Beigetragen von Hugo van Kemenade in gh-118798.)

importlib.abc

itertools

  • Die Unterstützung für die Operationen copy, deepcopy und pickle bei itertools-Iteratoren ist entfernt. Sie gaben seit Python 3.12 eine DeprecationWarning aus. (Beigetragen von Raymond Hettinger in gh-101588.)

pathlib

  • Die Unterstützung dafür, Path weitere Schlüsselwortargumente zu übergeben, ist entfernt. In früheren Versionen wurden solche Argumente übergangen. (Beigetragen von Barney Gale in gh-74033.)

  • Die Unterstützung dafür, PurePath.relative_to() und is_relative_to() weitere positionsbezogene Argumente zu übergeben, ist entfernt. In früheren Versionen wurden solche Argumente an other angehängt. (Beigetragen von Barney Gale in gh-78707.)

pkgutil

  • Die Funktionen get_loader() und find_loader() sind entfernt. Sie waren seit Python 3.12 als veraltet markiert. (Beigetragen von Bénédikt Tran in gh-97850.)

pty

  • Die Funktionen master_open() und slave_open() sind entfernt. Sie waren seit Python 3.12 als veraltet markiert. Verwende stattdessen pty.openpty(). (Beigetragen von Nikita Sobolev in gh-118824.)

sqlite3

  • version und version_info sind aus dem Modul sqlite3 entfernt. Verwende sqlite_version und sqlite_version_info, um die tatsächliche Versionsnummer der zur Laufzeit verwendeten SQLite-Bibliothek zu erfahren. (Beigetragen von Hugo van Kemenade in gh-118924.)

  • Eine Folge von Parametern mit benannten Platzhaltern zu verwenden löst jetzt einen ProgrammingError aus. Es war seit Python 3.12 als veraltet markiert. (Beigetragen von Erlend E. Aasland in gh-118928 und gh-101693.)

urllib

  • Die Klasse Quoter ist aus urllib.parse entfernt. Sie war seit Python 3.11 als veraltet markiert. (Beigetragen von Nikita Sobolev in gh-118827.)

  • Die Klassen URLopener und FancyURLopener sind aus urllib.request entfernt. Sie waren seit Python 3.3 als veraltet markiert.

    myopener.open() lässt sich durch urlopen() ersetzen, myopener.retrieve() durch urlretrieve(). Anpassungen an den Opener-Klassen lassen sich dadurch ersetzen, dass man angepasste Handler an build_opener() übergibt. (Beigetragen von Barney Gale in gh-84850.)

Als veraltet markiert

Neu als veraltet markiert

  • Eine komplexe Zahl als Argument real oder imag an den Konstruktor complex() zu übergeben ist jetzt als veraltet markiert. Komplexe Zahlen sollten nur als einzelnes positionsbezogenes Argument übergeben werden. (Beigetragen von Serhiy Storchaka in gh-109218.)

  • argparse:

    • Das nicht dokumentierte Schlüsselwortargument prefix_chars an die Methode add_argument_group() zu übergeben ist jetzt als veraltet markiert. (Beigetragen von Savannah Ostrowski in gh-125563.)

    • Der Typumwandler argparse.FileType ist als veraltet markiert. Alles, was mit der Verwaltung von Ressourcen zu tun hat, sollte nachgelagert geschehen, nachdem die Argumente ausgewertet sind. (Beigetragen von Serhiy Storchaka in gh-58032.)

  • asyncio:

  • codecs: Die Funktion codecs.open() ist jetzt als veraltet markiert und wird in einer künftigen Python-Version entfernt. Verwende stattdessen open(). (Beigetragen von Inada Naoki in gh-133036.)

  • ctypes:

    • Auf Plattformen außer Windows ist es jetzt als veraltet markiert, Structure._pack_ zu setzen, um ein MSVC-verträgliches voreingestelltes Speicherlayout zu verwenden. Setze stattdessen Structure._layout_ auf 'ms'. Entfernt wird das in Python 3.19. (Beigetragen von Petr Viktorin in gh-131747.)

    • ctypes.POINTER() auf einer Zeichenkette aufzurufen ist jetzt als veraltet markiert. Verwende für selbstbezügliche Strukturen unvollständige Typen. Außerdem ist der interne ctypes._pointer_type_cache als veraltet markiert. Die aktualisierten Umsetzungsdetails stehen unter ctypes.POINTER(). (Beigetragen von Sergey Myrianov in gh-100926.)

  • functools: Die Python-Umsetzung von functools.reduce() mit function oder sequence als Schlüsselwortargumenten aufzurufen ist jetzt als veraltet markiert. Die Parameter werden in Python 3.16 nur noch positionsbezogen angenommen. (Beigetragen von Kirill Podoprigora in gh-121676.)

  • logging: Die Unterstützung für eigene Logging-Handler mit dem Argument strm ist jetzt als veraltet markiert, die Entfernung ist für Python 3.16 geplant. Definiere Handler stattdessen mit dem Argument stream. (Beigetragen von Mariusz Felisiak in gh-115032.)

  • mimetypes: Gültige Erweiterungen sind für mimetypes.MimeTypes.add_type() entweder leer oder müssen mit ‚.‘ beginnen. Erweiterungen ohne Punkt sind als veraltet markiert und lösen in Python 3.16 einen ValueError aus. (Beigetragen von Hugo van Kemenade in gh-75223.)

  • nturl2path: Dieses Modul ist jetzt als veraltet markiert. Rufe stattdessen urllib.request.url2pathname() und pathname2url() auf. (Beigetragen von Barney Gale in gh-125866.)

  • os: Die Funktionen os.popen() und os.spawn* sind jetzt sanft abgekündigt. Sie sollten für neuen Code nicht mehr verwendet werden. Empfohlen wird stattdessen das Modul subprocess. (Beigetragen von Victor Stinner in gh-120743.)

  • pathlib: pathlib.PurePath.as_uri() ist jetzt als veraltet markiert, die Entfernung ist für Python 3.19 geplant. Verwende stattdessen pathlib.Path.as_uri(). (Beigetragen von Barney Gale in gh-123599.)

  • pdb: Das nicht dokumentierte Attribut pdb.Pdb.curframe_locals ist jetzt eine als veraltet markierte, nur lesbare Eigenschaft, die in einer künftigen Python-Version entfernt wird. Durch den in Python 3.13 mit PEP 667 eingeführten, kaum ins Gewicht fallenden dynamischen Zugriff auf die lokalen Variablen eines Rahmens wird der Verweis auf den Zwischenspeicher, der vorher in diesem Attribut lag, nicht mehr gebraucht. Abgeleitete Debugger sollten in Python 3.13 und späteren Versionen unmittelbar auf pdb.Pdb.curframe.f_locals zugreifen. (Beigetragen von Tian Gao in gh-124369 und gh-125951.)

  • symtable: symtable.Class.get_methods() ist mangels Interesse als veraltet markiert, die Entfernung ist für Python 3.16 geplant. (Beigetragen von Bénédikt Tran in gh-119698.)

  • tkinter: Die tkinter.Variable-Methoden trace_variable(), trace_vdelete() und trace_vinfo() sind jetzt als veraltet markiert. Verwende stattdessen trace_add(), trace_remove() und trace_info(). (Beigetragen von Serhiy Storchaka in gh-120220.)

  • urllib.parse: In parse_qsl() und parse_qs() Objekte mit falschen Werten (wie 0 und []) anzunehmen ist jetzt als veraltet markiert, ausgenommen leere Zeichenketten, bytes-ähnliche Objekte und None. (Beigetragen von Serhiy Storchaka in gh-116897.)

Geplante Entfernung in Python 3.15

  • Das Importsystem:

    • __cached__ an einem Modul zu setzen, ohne __spec__.cached zu setzen, ist als veraltet markiert. In Python 3.15 wird __cached__ vom Importsystem und von der Standardbibliothek nicht mehr gesetzt und nicht mehr berücksichtigt. (gh-97879)

    • __package__ an einem Modul zu setzen, ohne __spec__.parent zu setzen, ist als veraltet markiert. In Python 3.15 wird __package__ vom Importsystem und von der Standardbibliothek nicht mehr gesetzt und nicht mehr berücksichtigt. (gh-97879)

  • ctypes:

    • Die nicht dokumentierte Funktion ctypes.SetPointerType() ist seit Python 3.13 als veraltet markiert.

  • http.server:

    • Die überholte und selten verwendete Klasse CGIHTTPRequestHandler ist seit Python 3.13 als veraltet markiert. Es gibt keinen unmittelbaren Ersatz. Alles ist besser als CGI, um einen Webserver an einen Request-Handler anzubinden.

    • Der Schalter --cgi der Befehlszeilenschnittstelle python -m http.server ist seit Python 3.13 als veraltet markiert.

  • importlib:

    • Methode load_module(): verwende stattdessen exec_module().

  • pathlib:

    • .PurePath.is_reserved() ist seit Python 3.13 als veraltet markiert. Verwende os.path.isreserved(), um unter Windows vorbehaltene Pfade zu erkennen.

  • platform:

    • platform.java_ver() ist seit Python 3.13 als veraltet markiert. Diese Funktion ist nur für die Unterstützung von Jython nützlich, hat eine verwirrende API und ist kaum getestet.

  • sysconfig:

  • threading:

    • RLock() nimmt in Python 3.15 keine Argumente mehr an. Argumente zu übergeben ist seit Python 3.14 als veraltet markiert, denn die Python-Fassung erlaubt keine Argumente, während die C-Fassung beliebig viele positionsbezogene oder Schlüsselwortargumente annimmt und sie alle übergeht.

  • types:

    • types.CodeType: Der Zugriff auf codeobject.co_lnotab wurde in PEP 626 seit 3.10 als veraltet markiert und sollte in 3.12 entfernt werden, bekam dort aber erst eine richtige DeprecationWarning. Entfernt werden kann er in 3.15. (Beigetragen von Nikita Sobolev in gh-101866.)

  • typing:

    • Die nicht dokumentierte Schreibweise mit Schlüsselwortargumenten, um NamedTuple-Klassen zu erzeugen (zum Beispiel Point = NamedTuple("Point", x=int, y=int)), ist seit Python 3.13 als veraltet markiert. Verwende stattdessen die klassenbasierte oder die funktionale Schreibweise.

    • Bei der funktionalen Schreibweise von TypedDicts ist es seit Python 3.13 als veraltet markiert, dem Parameter fields keinen Wert zu übergeben (TD = TypedDict("TD")) oder None zu übergeben (TD = TypedDict("TD", None)). Verwende class TD(TypedDict): pass oder TD = TypedDict("TD", {}), um ein TypedDict ohne Felder zu erzeugen.

    • Die Dekoratorfunktion @typing.no_type_check_decorator ist seit Python 3.13 als veraltet markiert. Nach acht Jahren im Modul typing wird sie noch von keinem größeren Typprüfer unterstützt.

  • Module sre_compile, sre_constants und sre_parse.

  • wave:

    • Die Methoden getmark(), setmark() und getmarkers() der Klassen Wave_read und Wave_write sind seit Python 3.13 als veraltet markiert.

  • zipimport:

    • zipimport.zipimporter.load_module() ist seit Python 3.10 als veraltet markiert. Verwende stattdessen exec_module(). (gh-125746.)

Geplante Entfernung in Python 3.16

Geplante Entfernung in Python 3.17

  • datetime:

    • Aufrufe von strptime() mit einer Formatzeichenkette, die %e (Tag des Monats) ohne Jahr enthält. Dies ist seit Python 3.15 veraltet. (Beigetragen von Stan Ulbrych in gh-70647.)

  • collections.abc:

    • collections.abc.ByteString soll in Python 3.17 entfernt werden.

      Verwende isinstance(obj, collections.abc.Buffer), um zur Laufzeit zu prüfen, ob obj das Buffer-Protokoll implementiert. Für Typannotationen verwende entweder Buffer oder eine Union, die explizit die von deinem Code unterstützten Typen angibt (z. B. bytes | bytearray | memoryview).

      ByteString war ursprünglich als abstrakte Klasse gedacht, die als Obertyp sowohl von bytes als auch von bytearray dienen sollte. Da die ABC jedoch nie Methoden hatte, sagte das Wissen, dass ein Objekt eine Instanz von ByteString ist, nie etwas Nützliches über das Objekt aus. Andere gängige Puffertypen wie memoryview wurden ebenfalls nie als Untertypen von ByteString verstanden (weder zur Laufzeit noch von statischen Typprüfern).

      Weitere Details findest du in PEP 688. (Beigetragen von Shantanu Jain in gh-91896.)

  • encodings:

    • Die Übergabe von Namen für encoding, die nicht ASCII sind, an encodings.normalize_encoding() ist veraltet und soll in Python 3.17 entfernt werden. (Beigetragen von Stan Ulbrych in gh-136702.)

  • profile:

    • Das Modul profile ist veraltet und wird in Python 3.17 entfernt. Verwende stattdessen profiling.tracing, das eine kompatible API bietet. Details findest du in PEP 799. (Beigetragen von Pablo Galindo und László Kiss Kollár in gh-138122.)

  • webbrowser:

    • webbrowser.MacOSXOSAScript ist zugunsten von webbrowser.MacOS veraltet. (gh-137586)

  • typing:

    • Vor Python 3.14 wurden Unions im alten Stil mit der privaten Klasse typing._UnionGenericAlias implementiert. Diese Klasse wird für die Implementierung nicht mehr benötigt, wurde aber aus Gründen der Abwärtskompatibilität beibehalten. Ihre Entfernung ist für Python 3.17 geplant. Verwende dokumentierte Hilfsfunktionen zur Introspektion wie typing.get_origin() und typing.get_args(), statt dich auf private Implementierungsdetails zu verlassen.

    • typing.ByteString, seit Python 3.9 veraltet, soll in Python 3.17 entfernt werden.

      Verwende isinstance(obj, collections.abc.Buffer), um zur Laufzeit zu prüfen, ob obj das Buffer-Protokoll implementiert. Für Typannotationen verwende entweder Buffer oder eine Union, die explizit die von deinem Code unterstützten Typen angibt (z. B. bytes | bytearray | memoryview).

      ByteString war ursprünglich als abstrakte Klasse gedacht, die als Obertyp sowohl von bytes als auch von bytearray dienen sollte. Da die ABC jedoch nie Methoden hatte, sagte das Wissen, dass ein Objekt eine Instanz von ByteString ist, nie etwas Nützliches über das Objekt aus. Andere gängige Puffertypen wie memoryview wurden ebenfalls nie als Untertypen von ByteString verstanden (weder zur Laufzeit noch von statischen Typprüfern).

      Weitere Details findest du in PEP 688. (Beigetragen von Shantanu Jain in gh-91896.)

  • tkinter:

    • Bei tkinter.Variable sollen die seit Python 3.14 veralteten Methoden trace_variable(), trace() (ein Alias von trace_variable()), trace_vdelete() und trace_vinfo() in Python 3.17 entfernt werden. Verwende stattdessen trace_add(), trace_remove() und trace_info(). (Beigetragen von Serhiy Storchaka in gh-120220.)

Geplante Entfernung in Python 3.18

  • Es wird kein boolescher Wert mehr akzeptiert, wenn ein Dateideskriptor erwartet wird. (Beigetragen von Serhiy Storchaka in gh-82626.)

  • decimal:

    • Der nicht standardkonforme und undokumentierte Formatbezeichner 'N' für Decimal, der nur in der C-Implementierung des Moduls decimal unterstützt wird, ist seit Python 3.13 veraltet. (Beigetragen von Serhiy Storchaka in gh-89902.)

  • Durch PEP 829 festgelegte Abkündigungen:

    • Zeilen mit import in Dateien vom Typ name.pth werden stillschweigend ignoriert.

    (Beigetragen von Barry Warsaw in gh-148641.)

Geplante Entfernung in Python 3.19

  • ctypes:

    • Das implizite Umschalten auf das MSVC-kompatible Struct-Layout, wenn auf Nicht-Windows-Plattformen _pack_, aber nicht _layout_ gesetzt wird.

  • hashlib:

    • Bei Konstruktoren von Hash-Funktionen wie new() oder den direkt nach dem Hash benannten Konstruktoren wie md5() und sha256() konnte dem optionalen Parameter für die Anfangsdaten in verschiedenen Implementierungen von hashlib auch ein Schlüsselwortargument namens data= oder string= übergeben werden.

      Die Unterstützung des Schlüsselwortarguments string ist jetzt veraltet und soll in Python 3.19 entfernt werden.

      Vor Python 3.13 wurde der Schlüsselwortparameter string je nach Backend-Implementierung der Hash-Funktionen nicht korrekt unterstützt. Übergib die Anfangsdaten für die größtmögliche Abwärtskompatibilität am besten als Positionsargument.

  • http.cookies:

  • imaplib:

    • Das Ändern von IMAP4.file ist jetzt veraltet und soll in Python 3.19 entfernt werden. Diese Eigenschaft wird nicht mehr verwendet, und das Ändern ihres Werts schließt die aktuelle Datei nicht automatisch.

      Vor Python 3.14 wurde diese Eigenschaft verwendet, um die entsprechenden Methoden read() und readline() von IMAP4 zu implementieren. Das ist seitdem nicht mehr der Fall.

Geplante Entfernung in Python 3.20

Geplante Entfernung in zukünftigen Versionen

Die folgenden APIs werden in Zukunft entfernt, auch wenn derzeit noch kein Termin für ihre Entfernung feststeht.

  • argparse:

    • Das Verschachteln von Argumentgruppen und von sich gegenseitig ausschließenden Gruppen ist veraltet.

    • Die Übergabe des undokumentierten Schlüsselwortarguments prefix_chars an add_argument_group() ist jetzt veraltet.

    • Der Typkonverter argparse.FileType ist veraltet.

  • builtins:

    • Generatoren: Die Signatur throw(type, exc, tb) und athrow(type, exc, tb) ist veraltet: Verwende stattdessen throw(exc) und athrow(exc), die Signatur mit einem einzigen Argument.

    • Derzeit akzeptiert Python numerische Literale, auf die unmittelbar Schlüsselwörter folgen, zum Beispiel 0in x, 1or x, 0if 1else 2. Das ermöglicht verwirrende und mehrdeutige Ausdrücke wie [0x1for x in y] (was als [0x1 for x in y] oder als [0x1f or x in y] interpretiert werden kann). Eine Syntaxwarnung wird ausgelöst, wenn auf das numerische Literal unmittelbar eines der Schlüsselwörter and, else, for, if, in, is und or folgt. In einer künftigen Version wird daraus ein Syntaxfehler. (gh-87999)

    • Unterstützung dafür, dass die Methoden __index__() und __int__() einen Typ zurückgeben, der kein int ist: Diese Methoden müssen künftig eine Instanz einer strikten Unterklasse von int zurückgeben.

    • Unterstützung dafür, dass die Methode __float__() eine strikte Unterklasse von float zurückgibt: Diese Methoden müssen künftig eine Instanz von float zurückgeben.

    • Unterstützung dafür, dass die Methode __complex__() eine strikte Unterklasse von complex zurückgibt: Diese Methoden müssen künftig eine Instanz von complex zurückgeben.

    • Die Übergabe einer komplexen Zahl als Argument real oder imag an den Konstruktor complex() ist jetzt veraltet. Sie sollte nur als einziges Positionsargument übergeben werden. (Beigetragen von Serhiy Storchaka in gh-109218.)

  • calendar: Die Konstanten calendar.January und calendar.February sind veraltet und werden durch calendar.JANUARY und calendar.FEBRUARY ersetzt. (Beigetragen von Prince Roshan in gh-103636.)

  • codecs: Verwende open() statt codecs.open(). (gh-133038)

  • codeobject.co_lnotab: Verwende stattdessen die Methode codeobject.co_lines().

  • datetime:

    • utcnow(): Verwende datetime.datetime.now(tz=datetime.UTC).

    • utcfromtimestamp(): Verwende datetime.datetime.fromtimestamp(timestamp, tz=datetime.UTC).

  • gettext: Der Pluralwert muss eine Ganzzahl sein.

  • importlib:

    • cache_from_source(): Der Parameter debug_override ist veraltet: Verwende stattdessen den Parameter optimization.

  • importlib.metadata:

    • Die Tupel-Schnittstelle von EntryPoints.

    • Implizites None bei Rückgabewerten.

  • logging: Die Methode warn() ist seit Python 3.3 veraltet, verwende stattdessen warning().

  • mailbox: Die Verwendung von StringIO-Eingaben und Textmodus ist veraltet, verwende stattdessen BytesIO und Binärmodus.

  • os: Der Aufruf von os.register_at_fork() in einem Prozess mit mehreren Threads.

  • os.path: os.path.commonprefix() ist veraltet, verwende os.path.commonpath() für Pfadpräfixe. Die Funktion os.path.commonprefix() wird als veraltet markiert, weil ihr Name und ihr Modul irreführend sind. Die Funktion ist für Pfadpräfixe nicht sicher, obwohl sie in einem Modul zur Pfadbearbeitung enthalten ist. Dadurch lassen sich mit ihr leicht versehentlich Path-Traversal-Schwachstellen in Python-Programme einbauen.

  • pydoc.ErrorDuringImport: Ein Tupelwert für den Parameter exc_info ist veraltet, verwende eine Ausnahmeinstanz.

  • re: Für numerische Gruppenreferenzen und Gruppennamen in regulären Ausdrücken gelten jetzt strengere Regeln. Als numerische Referenz wird jetzt nur noch eine Folge von ASCII-Ziffern akzeptiert. Der Gruppenname in Bytes-Mustern und Ersetzungszeichenketten darf jetzt nur noch ASCII-Buchstaben, Ziffern und Unterstriche enthalten. (Beigetragen von Serhiy Storchaka in gh-91760.)

  • shutil: Der Parameter onerror von rmtree() ist seit Python 3.12 veraltet. Verwende stattdessen den Parameter onexc.

  • Optionen und Protokolle von ssl:

    • ssl.SSLContext ohne Protokollargument ist veraltet.

    • ssl.SSLContext: set_npn_protocols() und selected_npn_protocol() sind veraltet: Verwende stattdessen ALPN.

    • Optionen ssl.OP_NO_SSL*

    • Optionen ssl.OP_NO_TLS*

    • ssl.PROTOCOL_SSLv3

    • ssl.PROTOCOL_TLS

    • ssl.PROTOCOL_TLSv1

    • ssl.PROTOCOL_TLSv1_1

    • ssl.PROTOCOL_TLSv1_2

    • ssl.TLSVersion.SSLv3

    • ssl.TLSVersion.TLSv1

    • ssl.TLSVersion.TLSv1_1

  • Methoden von threading:

  • typing.Text (gh-92332).

  • Die interne Klasse typing._UnionGenericAlias wird nicht mehr zur Implementierung von typing.Union verwendet. Um die Kompatibilität mit Benutzern dieser privaten Klasse zu wahren, wird bis mindestens Python 3.17 ein Kompatibilitäts-Shim bereitgestellt. (Beigetragen von Jelle Zijlstra in gh-105499.)

  • unittest.IsolatedAsyncioTestCase: Es ist veraltet, aus einem Testfall einen Wert zurückzugeben, der nicht None ist.

  • Veraltete Funktionen in urllib.parse: Verwende stattdessen urlparse()

    • splitattr()

    • splithost()

    • splitnport()

    • splitpasswd()

    • splitport()

    • splitquery()

    • splittag()

    • splittype()

    • splituser()

    • splitvalue()

    • to_bytes()

  • wsgiref: SimpleHandler.stdout.write() sollte keine teilweisen Schreibvorgänge durchführen.

  • xml.etree.ElementTree: Das Prüfen des Wahrheitswerts eines Element ist veraltet. In einer künftigen Version wird es immer True zurückgeben. Verwende stattdessen explizite Prüfungen mit len(elem) oder elem is not None.

  • sys._clear_type_cache() ist veraltet: Verwende stattdessen sys._clear_internal_caches().

CPython Bytecode Änderungen

  • Der Opcode BINARY_SUBSCR ist durch den Opcode BINARY_OP mit dem Oparg NB_SUBSCR ersetzt. (Beigetragen von Irit Katriel in gh-100239.)

  • Die Opcodes BUILD_INTERPOLATION und BUILD_TEMPLATE sind hinzugekommen, um neue Instanzen von Interpolation beziehungsweise Template zu erzeugen. (Beigetragen von Lysandros Nikolaou und anderen in gh-132661, siehe auch PEP 750: Template-Strings).

  • Der Opcode BUILD_CONST_KEY_MAP ist entfernt. Verwende stattdessen BUILD_MAP. (Beigetragen von Mark Shannon in gh-122160.)

  • Der Opcode LOAD_ASSERTION_ERROR ist durch LOAD_COMMON_CONSTANT ersetzt. Außerdem ist Unterstützung dafür hinzugekommen, NotImplementedError zu laden.

  • Die Opcodes LOAD_FAST_BORROW und LOAD_FAST_BORROW_LOAD_FAST_BORROW sind hinzugekommen, um den Aufwand für das Zählen von Referenzen zu senken, wenn der Interpreter nachweisen kann, dass die Referenz im Rahmen länger lebt als die auf den Stapel geladene Referenz. (Beigetragen von Matt Page in gh-130704.)

  • Der Opcode LOAD_SMALL_INT ist hinzugekommen. Er legt eine kleine ganze Zahl, die dem oparg entspricht, auf den Stapel. Der Opcode RETURN_CONST ist entfernt, weil er nicht mehr verwendet wird. (Beigetragen von Mark Shannon in gh-125837.)

  • Die neue Anweisung LOAD_SPECIAL ist hinzugekommen. Für with- und async with-Anweisungen wird Code mit der neuen Anweisung erzeugt. Die Anweisungen BEFORE_WITH und BEFORE_ASYNC_WITH sind entfernt. (Beigetragen von Mark Shannon in gh-120507.)

  • Der Opcode POP_ITER ist hinzugekommen, um „virtuelle“ Iteratoren zu unterstützen. (Beigetragen von Mark Shannon in gh-132554.)

Pseudo-Anweisungen

  • Die Pseudo-Anweisung ANNOTATIONS_PLACEHOLDER ist hinzugekommen, um teilweise ausgeführte Annotationen auf Modulebene mit verzögerter Auswertung von Annotationen zu unterstützen. (Beigetragen von Jelle Zijlstra in gh-130907.)

  • Die Pseudo-Anweisung BINARY_OP_EXTEND ist hinzugekommen. Sie führt ein Funktionspaar aus (eine Wächter- und eine Spezialisierungsfunktion), auf das über den Inline-Zwischenspeicher zugegriffen wird. (Beigetragen von Irit Katriel in gh-100239.)

  • Drei Spezialisierungen für CALL_KW sind hinzugekommen: CALL_KW_PY für Aufrufe von Python-Funktionen, CALL_KW_BOUND_METHOD für Aufrufe gebundener Methoden und CALL_KW_NON_PY für alle übrigen Aufrufe. (Beigetragen von Mark Shannon in gh-118093.)

  • Die Pseudo-Anweisungen JUMP_IF_TRUE und JUMP_IF_FALSE sind hinzugekommen, bedingte Sprünge, die den Stapel nicht verändern. Sie ersetzen die Folge COPY 1, TO_BOOL, POP_JUMP_IF_TRUE/FALSE. (Beigetragen von Irit Katriel in gh-124285.)

  • Die Pseudo-Anweisung LOAD_CONST_MORTAL ist hinzugekommen. (Beigetragen von Mark Shannon in gh-128685.)

  • Die Pseudo-Anweisung LOAD_CONST_IMMORTAL ist hinzugekommen. Sie tut dasselbe wie LOAD_CONST, arbeitet bei unsterblichen Objekten aber effizienter. (Beigetragen von Mark Shannon in gh-125837.)

  • Die Pseudo-Anweisung NOT_TAKEN ist hinzugekommen; sys.monitoring verwendet sie, um Verzweigungsereignisse aufzuzeichnen (etwa BRANCH_LEFT). (Beigetragen von Mark Shannon in gh-122548.)

Änderungen an der C-API

C-API zur Konfiguration von Python

Eine C-API PyInitConfig ist hinzugekommen, um die Initialisierung von Python ohne C-Strukturen einzustellen und künftig ABI-verträgliche Änderungen zu ermöglichen.

Die C-API PyConfig aus PEP 587 ist vervollständigt: PyInitConfig_AddModule() ist hinzugekommen, womit sich ein eingebautes Erweiterungsmodul hinzufügen lässt – ein Feature, das früher als „inittab“ bezeichnet wurde.

Die Funktionen PyConfig_Get() und PyConfig_Set() sind hinzugekommen, um die aktuelle Konfiguration zur Laufzeit zu lesen und zu setzen.

PEP 587 „Python Initialization Configuration“ hat alle Wege zusammengeführt, die Initialisierung von Python einzustellen. Dieses PEP führt darüber hinaus die Konfiguration der Vorinitialisierung und der Initialisierung von Python in einer einzigen API zusammen. Außerdem bietet dieses PEP nur noch eine Möglichkeit, Python einzubetten, statt der zwei Möglichkeiten „Python“ und „Isolated“ (PEP 587), was die API weiter vereinfacht.

Die tiefer liegende PyConfig-API aus PEP 587 bleibt für Anwendungsfälle verfügbar, in denen eine engere Verzahnung mit den Umsetzungsdetails von CPython gewollt ist (etwa um die volle Funktionalität der Befehlszeilenschnittstelle von CPython samt ihrer Konfigurationsmechanismen nachzubilden).

(Beigetragen von Victor Stinner in gh-107954.)

Siehe auch

PEP 741 und PEP 587

Neue Features in der C-API

Änderungen an der eingeschränkten C-API

Entfernte C-APIs

  • Unveränderliche Typen mit veränderlichen Basisklassen zu erzeugen war in Python 3.12 als veraltet markiert und löst jetzt einen TypeError aus. (Beigetragen von Nikita Sobolev in gh-119775.)

  • Das Element PyDictObject.ma_version_tag ist entfernt. Es war in Python 3.12 als veraltet markiert. Verwende stattdessen die API PyDict_AddWatcher(). (Beigetragen von Sam Gross in gh-124296.)

  • Die private Funktion _Py_InitializeMain() ist entfernt. Sie war eine vorläufige API, die mit PEP 587 in Python 3.8 hinzugekommen war. (Beigetragen von Victor Stinner in gh-129033.)

  • Die nicht dokumentierten APIs Py_C_RECURSION_LIMIT und PyThreadState.c_recursion_remaining sind entfernt. Sie kamen in 3.13 hinzu und sind ohne Abkündigung entfernt worden. Verwende Py_EnterRecursiveCall(), um C-Code gegen davonlaufende Rekursion abzusichern. (Entfernt von Petr Viktorin in gh-133079, siehe auch gh-130396.)

Veraltete C-APIs

Geplante Entfernung in Python 3.15

Geplante Entfernung in Python 3.16

  • Die mitgelieferte Kopie von libmpdec.

Geplante Entfernung in Python 3.18

Geplante Entfernung in zukünftigen Versionen

Die folgenden APIs sind als veraltet markiert und werden entfernt, auch wenn für die Entfernung derzeit kein Zeitpunkt festgelegt ist.

Änderungen am Build

  • PEP 776: Emscripten ist jetzt eine offiziell unterstützte Plattform auf Stufe 3. Im Rahmen dieser Arbeit wurden mehr als 25 Fehler in der libc von Emscripten behoben. Emscripten unterstützt jetzt ctypes, termios und fcntl sowie versuchsweise die neue voreingestellte interaktive Shell. (Beigetragen von R. Hood Chatham in gh-127146, gh-127683 und gh-136931.)

  • Offizielle Binärpakete für Android werden jetzt auf python.org bereitgestellt.

  • Zum Erzeugen von configure wird jetzt GNU Autoconf 2.72 benötigt. (Beigetragen von Erlend Aasland in gh-115765.)

  • wasm32-unknown-emscripten ist jetzt eine Plattform der Stufe 3 nach PEP 11. (Beigetragen von R. Hood Chatham in gh-127146, gh-127683 und gh-136931.)

  • Das Binden an python3*.lib über #pragma lässt sich jetzt mit Py_NO_LINK_LIB abschalten. (Beigetragen von Jean-Christophe Fillion-Robin in gh-82909.)

  • CPython schaltet für mehr Sicherheit jetzt standardmäßig eine Reihe empfohlener Compiler-Optionen ein. Mit der configure-Option --disable-safety lassen sie sich abschalten, mit der Option --enable-slower-safety kommt ein größerer Satz von Compiler-Optionen hinzu, allerdings auf Kosten der Geschwindigkeit.

  • Das Makro WITH_FREELISTS und die configure-Option --without-freelists sind entfernt.

  • Mit der neuen configure-Option --with-tail-call-interp lässt sich der versuchsweise eingebaute Tail-Call-Interpreter einschalten. Weitere Einzelheiten unter Eine neue Art von Interpreter.

  • Um die neue Unterstützung für Fehlersuche aus der Ferne abzuschalten, verwende die configure-Option --without-remote-debug. Das kann aus Sicherheitsgründen sinnvoll sein.

  • Anwendungen für iOS und macOS lassen sich jetzt so einstellen, dass die Inhalte von stdout und stderr in das Systemprotokoll umgeleitet werden. (Beigetragen von Russell Keith-Magee in gh-127592.)

  • Die Testumgebung für iOS kann die Testausgabe jetzt schon während des laufenden Tests übertragen. Sie lässt sich auch verwenden, um die Testsuite anderer Projekte als CPython selbst auszuführen. (Beigetragen von Russell Keith-Magee in gh-127592.)

build-details.json

Python-Installationen enthalten jetzt eine neue Datei, build-details.json. Das ist ein unveränderliches JSON-Dokument mit Angaben zum Build von CPython. Damit lässt sich der Build untersuchen, ohne Code ausführen zu müssen. Nützlich ist das zum Beispiel für Python-Starter, für Cross-Kompilierung und Ähnliches.

build-details.json muss im plattformunabhängigen Verzeichnis der Standardbibliothek installiert sein. Das entspricht dem sysconfig-Installationspfad ‚stdlib‘, der sich mit sysconfig.get_path('stdlib') ermitteln lässt.

Siehe auch

PEP 739 – build-details.json 1.0 – eine unveränderliche Beschreibungsdatei für Angaben zum Python-Build

Einstellung der PGP-Signaturen

Für Veröffentlichungen von Python 3.14 und künftiger Versionen werden keine PGP-Signaturen (Pretty Good Privacy) mehr bereitgestellt. Um CPython-Artefakte zu überprüfen, müssen die Prüfunterlagen von Sigstore verwendet werden. Veröffentlichungen werden seit Python 3.11 mit Sigstore signiert.

Diese Änderung am Veröffentlichungsprozess ist in PEP 761 festgelegt.

Free-Threaded Python wird offiziell unterstützt

Der Free-Threaded-Build von Python wird jetzt unterstützt und ist nicht mehr nur ein Versuch. Das ist der Beginn von Phase II, in der Free-Threaded Python offiziell unterstützt wird, aber weiterhin wahlweise zur Verfügung steht.

Das Free-Threading-Team ist überzeugt, dass das Projekt auf dem richtigen Weg ist, und weiß den anhaltenden Einsatz aller zu schätzen, die daran arbeiten, Free-Threading für eine breitere Verwendung in der Python-Gemeinschaft bereitzumachen.

Mit diesen Empfehlungen und der Annahme dieses PEP sollte die Python-Entwicklergemeinschaft breit bekannt machen, dass Free-Threading jetzt und auch künftig eine unterstützte Build-Option von Python ist und dass es nicht ohne einen ordentlichen Abkündigungszeitplan entfernt wird.

Ob auf Phase III übergegangen wird, in der Free-Threading der voreingestellte oder der einzige Build von Python ist, ist noch nicht entschieden und hängt von vielen Umständen ab, in CPython selbst wie in der Gemeinschaft. Diese Entscheidung bleibt der Zukunft überlassen.

Siehe auch

PEP 779

Annahme von PEP 779

Binärpakete für den versuchsweisen Just-in-time-Compiler

Die offiziellen Binärpakete für macOS und Windows enthalten jetzt einen versuchsweisen Just-in-time-Compiler (JIT). Er ist für den Produktiveinsatz nicht empfohlen, lässt sich aber testen, indem man die Umgebungsvariable PYTHON_JIT=1 setzt. Nachgelagerte Quellcode-Builds und Distributoren können für ein ähnliches Verhalten die Konfigurationsoption --enable-experimental-jit=yes-off verwenden.

Der JIT steht noch am Anfang und wird aktiv weiterentwickelt. Entsprechend reicht die Wirkung auf die Geschwindigkeit je nach Arbeitslast üblicherweise von 10 % langsamer bis 20 % schneller. Um Tests und Bewertung zu erleichtern, steht im Namensraum sys._jit eine Reihe von Funktionen zur Introspektion bereit. Mit sys._jit.is_available() lässt sich feststellen, ob die laufende ausführbare Datei JIT-Kompilierung unterstützt, und mit sys._jit.is_enabled(), ob die JIT-Kompilierung für den aktuellen Prozess eingeschaltet ist.

Derzeit fehlt vor allem, dass native Debugger und Profiler wie gdb und perf nicht durch JIT-Rahmen hindurch abwickeln können (Python-Debugger und -Profiler wie pdb oder profile arbeiten unverändert weiter). Free-Threading-Builds unterstützen keine JIT-Kompilierung.

Melde gern alle Fehler und größeren Geschwindigkeitseinbrüche, auf die du stößt!

Siehe auch

PEP 744

Portierung auf Python 3.14

Dieser Abschnitt listet bereits beschriebene Änderungen und weitere Fehlerbehebungen auf, die Änderungen an deinem Code erfordern können.

Änderungen in der Python API

  • Auf Unix-Plattformen außer macOS ist forkserver jetzt die voreingestellte Startmethode für multiprocessing und ProcessPoolExecutor an der Stelle von fork.

    Einzelheiten unter (1) und (2).

    Wenn du auf NameErrors oder Pickling-Fehler aus multiprocessing oder concurrent.futures stößt, sieh dir die Einschränkungen von forkserver an.

    Diese Änderung betrifft weder Windows noch macOS, wo ‚spawn‘ die voreingestellte Startmethode bleibt.

  • functools.partial ist jetzt ein Methodendeskriptor. Hülle es in staticmethod() ein, wenn du das alte Verhalten beibehalten willst. (Beigetragen von Serhiy Storchaka und Dominykas Grigonis in gh-121027.)

  • Die Speicherbereinigung arbeitet jetzt inkrementell, wodurch sich das Verhalten von gc.collect() leicht ändert:

    • gc.collect(1): Führt ein Inkrement der Speicherbereinigung aus, statt Generation 1 zu bereinigen.

    • Andere Aufrufe von gc.collect() sind unverändert.

  • Die Funktion locale.nl_langinfo() setzt in manchen Fällen jetzt vorübergehend die Locale LC_CTYPE. Diese vorübergehende Änderung wirkt sich auf andere Threads aus. (Beigetragen von Serhiy Storchaka in gh-69998.)

  • pickle.dump() und pickle.dumps() lösen jetzt bei einigen Fehlern einen PicklingError aus, die vorher je nach Umsetzung einen AttributeError, ImportError, ValueError, UnicodeEncodeError oder PicklingError ausgelöst haben (zum Beispiel beim Picklen eines lokalen Objekts oder eines Objekts, dessen Modul sich nicht importieren lässt). Die ursprüngliche Ausnahme ist dem PicklingError als Ursache angehängt. Code, der diese Ausnahmen abgefangen hat, sollte auch PicklingError abfangen. (Beigetragen von Serhiy Storchaka in gh-122311.)

  • types.UnionType ist jetzt ein anderer Name für typing.Union, was zu einigen Verhaltensänderungen führt. Näheres weiter oben. (Beigetragen von Jelle Zijlstra in gh-105499.)

  • Das Verhalten von Annotationen zur Laufzeit hat sich in mehrerer Hinsicht geändert; Einzelheiten weiter oben. Der meiste Code, der mit Annotationen umgeht, sollte weiterhin funktionieren, einige nicht dokumentierte Einzelheiten können sich aber anders verhalten.

  • Da die Befehlszeilenschnittstelle von mimetypes öffentlich geworden ist, beendet sie sich bei einem Fehler jetzt mit 1 statt mit 0 und bei falschen Befehlszeilenparametern mit 2 statt mit 1. Fehlermeldungen werden jetzt nach stderr ausgegeben.

  • Das Muster \B in regulären Ausdrücken passt jetzt auf die leere Zeichenkette, wenn es als vollständiges Muster angegeben ist, was zu Verhaltensänderungen führen kann.

  • Unter FreeBSD enthält sys.platform die Hauptversionsnummer nicht mehr.

Änderungen bei Annotationen (PEP 649 und PEP 749)

Dieser Abschnitt gibt Hinweise zu Änderungen, die wegen der Umstellung auf die verzögerte Auswertung von Annotationen an Annotationen oder an Python-Code nötig sein können, der mit Annotationen umgeht oder sie untersucht.

In der großen Mehrheit der Fälle sind an funktionierendem Code aus älteren Python-Versionen keine Änderungen nötig.

Auswirkungen auf annotierten Code

Wenn du in deinem Code Annotationen definierst (zum Beispiel für einen statischen Typprüfer), betrifft diese Änderung dich wahrscheinlich nicht: Du kannst Annotationen weiterhin so schreiben wie in früheren Python-Versionen.

Vermutlich kannst du Zeichenketten in Anführungszeichen aus Annotationen entfernen, die häufig für Vorwärtsreferenzen verwendet werden. Ebenso kannst du, wenn du from __future__ import annotations verwendest, um Zeichenketten in Annotationen zu vermeiden, diesen Import gut weglassen, sobald du nur noch Python 3.14 und neuer unterstützt. Verlässt du dich allerdings auf Bibliotheken von Dritten, die Annotationen lesen, brauchen diese Bibliotheken unter Umständen erst Änderungen, damit sie wie erwartet mit Annotationen ohne Anführungszeichen arbeiten.

Auswirkungen auf Code, der __annotations__ liest

Wenn dein Code das Attribut __annotations__ an Objekten liest, willst du vielleicht Änderungen vornehmen, um Code zu unterstützen, der auf die verzögerte Auswertung von Annotationen setzt. Zum Beispiel kannst du annotationlib.get_annotations() mit dem Format FORWARDREF verwenden, wie es das Modul dataclasses jetzt tut.

Das externe Paket typing_extensions bietet teilweise Rückportierungen einiger Funktionalität des Moduls annotationlib, etwa der Aufzählung Format und der Funktion get_annotations(). Damit lässt sich versionsübergreifender Code schreiben, der das neue Verhalten in Python 3.14 nutzt.

from __future__ import annotations

In Python 3.7 kam mit PEP 563 die Future-Anweisung from __future__ import annotations hinzu, die alle Annotationen in Zeichenketten verwandelt.

Diese Anweisung ist jetzt allerdings als veraltet markiert und wird voraussichtlich in einer künftigen Python-Version entfernt. Dazu kommt es erst, nachdem Python 3.13 im Jahr 2029 das Ende seiner Lebensdauer erreicht hat, denn es ist die letzte Python-Version ohne Unterstützung für die verzögerte Auswertung von Annotationen.

In Python 3.14 verhält sich Code, der from __future__ import annotations verwendet, unverändert.

Änderungen an der C-API

  • Py_Finalize() löscht jetzt alle internierten Zeichenketten. Das ist rückwärts unverträglich für jede C-Erweiterung, die eine internierte Zeichenkette über einen Aufruf von Py_Finalize() hinaus festhält und sie nach einem Aufruf von Py_Initialize() weiterverwendet. Probleme aus diesem Verhalten führen üblicherweise zu Abstürzen während des folgenden Aufrufs von Py_Initialize(), weil auf nicht initialisierten Speicher zugegriffen wird. Zur Behebung lässt sich mit einem Address Sanitizer jede Verwendung nach dem Freigeben einer internierten Zeichenkette aufspüren, die dann beim Herunterfahren des Moduls freigegeben werden muss. (Beigetragen von Eddie Elizondo in gh-113601.)

  • Die C-API der Unicode-Ausnahmeobjekte löst jetzt einen TypeError aus, wenn ihr Ausnahmeargument kein UnicodeError-Objekt ist. (Beigetragen von Bénédikt Tran in gh-127691.)

Erwähnenswerte Änderungen in 3.14.5

gc

  • Die inkrementelle Speicherbereinigung, die mit Python 3.14.0 bis 3.14.4 ausgeliefert wurde, ist wegen einer Reihe von Meldungen über erheblichen Speicherdruck in Produktivumgebungen auf die generationsbasierte Speicherbereinigung aus 3.13 zurückgenommen. Einzelheiten unter Speicherbereinigung.