Neuigkeiten in Python 3.14

Herausgeber:

Adam Turner und Hugo van Kemenade

Dieser Artikel erklärt die neuen Funktionen in Python 3.14 im Vergleich zu 3.13. Python 3.14 wurde am 7. Oktober 2025 veröffentlicht. Vollständige Details finden Sie im Changelog.

Siehe auch

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

Zusammenfassung – Release-Highlights

Python 3.14 ist die neueste stabile Veröffentlichung der Python-Programmiersprache mit einer Mischung aus Änderungen an der Sprache, der Implementierung und der Standardbibliothek. Die größten Änderungen sind Template-String-Literale, verzögerte Auswertung von Annotationen und Unterstützung für Sub-Interpreter in der Standardbibliothek.

Die Bibliotheksänderungen umfassen erheblich verbesserte Fähigkeiten für Introspektion in asyncio, Unterstützung für Zstandard über ein neues Modul compression.zstd, Syntaxhervorhebung in der REPL sowie die üblichen Deprecations und Entfernungen und Verbesserungen in Bezug auf Benutzerfreundlichkeit und Korrektheit.

Dieser Artikel versucht nicht, eine vollständige Spezifikation aller neuen Funktionen zu geben, sondern bietet stattdessen einen praktischen Überblick. Für vollständige Details siehe die Dokumentation, wie z. B. die Library Reference und Language Reference. Um die vollständige Implementierung und das Design-Rationale für eine Änderung zu verstehen, siehe die PEP für eine bestimmte neue Funktion; Beachten Sie jedoch, dass PEPs normalerweise nicht auf dem neuesten Stand gehalten werden, sobald eine Funktion vollständig implementiert ist. Siehe Porting nach Python 3.14 für Anleitungen zur Aktualisierung von früheren Python-Versionen.


Interpreter-Verbesserungen

Signifikante Verbesserungen in der Standardbibliothek

C-API-Verbesserungen

Plattformunterstützung

Release-Änderungen

Neue Funktionen

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

Die Annotationen von Funktionen, Klassen und Modulen werden nicht mehr sofort ausgewertet. Stattdessen werden Annotationen in speziellen Annotate-Funktionen gespeichert und erst bei Bedarf ausgewertet (außer wenn from __future__ import annotations verwendet wird).

Diese Änderung zielt darauf ab, die Leistung und Benutzerfreundlichkeit von Annotationen in Python unter den meisten Umständen zu verbessern. Die Laufzeitkosten für die Definition von Annotationen werden minimiert, aber es bleibt möglich, Annotationen zur Laufzeit zu introspektieren. Es ist nicht mehr notwendig, Annotationen in Zeichenketten einzuschließen, wenn sie Vorwärtsreferenzen enthalten.

Das neue Modul annotationlib bietet Werkzeuge zur Inspektion von verzögerten Annotationen. Annotationen können im VALUE-Format (das Annotationen in Laufzeitwerte auswertet, ähnlich dem Verhalten in früheren Python-Versionen), im FORWARDREF-Format (das undefinierte Namen durch spezielle Markierungen ersetzt) und im STRING-Format (das Annotationen als Zeichenketten zurückgibt) ausgewertet werden.

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 Porting enthält Anleitungen zu Änderungen, die aufgrund dieser Änderungen möglicherweise erforderlich sind, obwohl der Code in den meisten Fällen weiterhin unverändert funktioniert.

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

Siehe auch

PEP 649

Verzögerte Auswertung von Annotationen mithilfe von Deskriptoren

PEP 749

Implementierung von PEP 649

PEP 734: Mehrere Interpreter in der Standardbibliothek

Die CPython-Laufzeitumgebung unterstützt die gleichzeitige Ausführung mehrerer Kopien von Python im selben Prozess und tut dies seit über 20 Jahren. Jede dieser separaten Kopien wird als „Interpreter“ bezeichnet. Diese Funktion war jedoch nur über die C-API verfügbar.

Diese Einschränkung wird in Python 3.14 mit dem neuen Modul concurrent.interpreters aufgehoben.

Es gibt mindestens zwei nennenswerte Gründe, warum die Verwendung mehrerer Interpreter erhebliche Vorteile bietet

  • Sie unterstützen ein neues (für Python) menschenfreundliches Nebenläufigkeitsmodell

  • echte Multi-Core-Parallelität

Für einige Anwendungsfälle verbessert die Nebenläufigkeit in Software die Effizienz und kann auf hoher Ebene das Design vereinfachen. Gleichzeitig ist die Implementierung und Wartung von Nebenläufigkeit, die über die einfachsten hinausgeht, oft eine Herausforderung für das menschliche Gehirn. Dies gilt insbesondere für reine Threads (z. B. threading), bei denen der gesamte Speicher zwischen allen Threads geteilt wird.

Mit mehreren isolierten Interpretern können Sie von einer Klasse von Nebenläufigkeitsmodellen wie Communicating Sequential Processes (CSP) oder dem Actor-Modell profitieren, die in anderen Programmiersprachen wie Smalltalk, Erlang, Haskell und Go erfolgreich waren. Stellen Sie sich mehrere Interpreter als Threads vor, aber mit optionalem Sharing.

Hinsichtlich der Multi-Core-Parallelität: Ab Python 3.12 sind Interpreter nun ausreichend voneinander isoliert, um parallel verwendet zu werden (siehe PEP 684). Dies eröffnet eine Vielzahl von CPU-intensiven Anwendungsfällen für Python, die durch das GIL eingeschränkt waren.

Die Verwendung mehrerer Interpreter ähnelt in vielerlei Hinsicht der Verwendung von multiprocessing, da beide isolierte logische „Prozesse“ bereitstellen, die parallel laufen können und standardmäßig nicht gemeinsam genutzt werden. Bei der Verwendung mehrerer Interpreter verbraucht eine Anwendung jedoch weniger Systemressourcen und arbeitet effizienter (da sie innerhalb desselben Prozesses bleibt). Stellen Sie sich mehrere Interpreter als eine Mischung aus der Isolation von Prozessen und der Effizienz von Threads vor.

Obwohl die Funktion seit Jahrzehnten existiert, wurden mehrere Interpreter aufgrund geringer Bekanntheit und fehlender Module in der Standardbibliothek nicht weit verbreitet genutzt. Folglich haben sie derzeit mehrere nennenswerte Einschränkungen, die sich voraussichtlich erheblich verbessern werden, da die Funktion nun Mainstream wird.

Aktuelle Einschränkungen

  • Das Starten jedes Interpreters wurde noch nicht optimiert

  • Jeder Interpreter verbraucht mehr Speicher als nötig (weitere Arbeiten zur umfassenden internen gemeinsamen Nutzung zwischen Interpretern sind im Gange)

  • Es gibt *noch* nicht viele Optionen zum tatsächlichen Teilen von Objekten oder anderen Daten zwischen Interpretern (außer memoryview)

  • Viele Drittanbieter-Erweiterungsmodule auf PyPI sind noch nicht mit mehreren Interpretern kompatibel (alle Standardbibliotheks-Erweiterungsmodule *sind* kompatibel)

  • Der Ansatz zur Entwicklung von Anwendungen, die mehrere isolierte Interpreter verwenden, ist für Python-Benutzer derzeit weitgehend unbekannt

Die Auswirkungen dieser Einschränkungen hängen von zukünftigen CPython-Verbesserungen, der Verwendung von Interpretern und der Lösung durch PyPI-Pakete ab. Abhängig von der Anwendung haben die Einschränkungen möglicherweise keine großen Auswirkungen, also probieren Sie es aus!

Darüber hinaus werden zukünftige CPython-Releases den Overhead reduzieren oder eliminieren und Dienstprogramme bereitstellen, die auf PyPI weniger relevant sind. In der Zwischenzeit können die meisten Einschränkungen auch durch Erweiterungsmodule behoben werden, was bedeutet, dass PyPI-Pakete Lücken für 3.14 schließen können, und sogar zurück bis 3.12, wo Interpreter endlich ordnungsgemäß isoliert wurden und aufhörten, das GIL zu teilen. Ebenso werden für High-Level-Abstraktionen über Interpreter hinweg Bibliotheken auf PyPI erwartet.

In Bezug auf Erweiterungsmodule wird an der Aktualisierung einiger PyPI-Projekte sowie von Tools wie Cython, pybind11, nanobind und PyO3 gearbeitet. Die Schritte zur Isolierung eines Erweiterungsmoduls finden Sie unter Isolating Extension Modules. Die Isolierung eines Moduls überschneidet sich stark mit dem, was zur Unterstützung von Free-Threading erforderlich ist. Daher wird die laufende Arbeit in der Community in diesem Bereich die Unterstützung für mehrere Interpreter beschleunigen.

Ebenfalls in 3.14 hinzugefügt: 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 benutzerdefinierte String-Verarbeitung. Sie teilen die vertraute Syntax von f-Strings, geben aber im Gegensatz zu f-Strings ein Objekt zurück, das die statischen und interpolierten Teile des Strings repräsentiert, anstatt eines einfachen str.

Um einen t-String zu schreiben, verwenden Sie ein 't' Präfix anstelle eines 'f'

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

Template-Objekte bieten Zugriff auf die statischen und interpolierten (in geschweiften Klammern) Teile eines Strings, *bevor* sie kombiniert werden. Iterieren Sie über Template-Instanzen, um auf ihre Teile in der richtigen Reihenfolge zuzugreifen

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

Es ist einfach, Code zum Verarbeiten von Template-Instanzen zu schreiben (oder aufzurufen). Hier ist zum Beispiel eine Funktion, die statische Teile in Kleinbuchstaben und Interpolation-Instanzen in Großbuchstaben rendert

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'

Da Template-Instanzen zur Laufzeit zwischen statischen Strings und Interpolationen unterscheiden, können sie zur Bereinigung von Benutzereingaben nützlich sein. Das Schreiben einer html()-Funktion, die Benutzereingaben in HTML maskiert, ist eine Übung, die dem Leser überlassen bleibt! Template-Verarbeitungscode kann eine verbesserte Flexibilität bieten. Beispielsweise könnte eine fortgeschrittenere html()-Funktion ein dict von HTML-Attributen direkt im Template akzeptieren

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

Natürlich muss der Template-Verarbeitungscode keine String-ähnliche Ausgabe zurückgeben. Eine noch *fortgeschrittenere* html() könnte einen benutzerdefinierten Typ zurückgeben, der eine DOM-ähnliche Struktur darstellt.

Mit t-Strings können Entwickler Systeme schreiben, die SQL bereinigen, sichere Shell-Operationen durchführen, Logging verbessern, moderne Ideen in der Webentwicklung (HTML, CSS usw.) angehen und leichte benutzerdefinierte Business-DSLs implementieren.

(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 externe Debugger-Schnittstelle

Python 3.14 führt eine Zero-Overhead-Debugging-Schnittstelle ein, die es Debuggern und Profilern ermöglicht, sicher an laufende Python-Prozesse anzudocken, ohne diese anzuhalten oder neu zu starten. Dies ist eine signifikante Verbesserung der Debugging-Fähigkeiten von Python, was bedeutet, dass unsichere Alternativen nicht mehr erforderlich sind.

Die neue Schnittstelle bietet sichere Ausführungspunkte für das Anhängen von Debugger-Code, ohne den normalen Ausführungspfad des Interpreters zu verändern oder Laufzeit-Overhead hinzuzufügen. Aus diesem Grund können Tools jetzt Python-Anwendungen in Echtzeit inspizieren und mit ihnen interagieren, was eine entscheidende Fähigkeit für hochverfügbare Systeme und Produktionsumgebungen ist.

Zur Bequemlichkeit ist diese Schnittstelle in der Funktion sys.remote_exec() implementiert. 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)

Diese Funktion erlaubt es, Python-Code an den nächsten sicheren Ausführungspunkt in einem Zielprozess zu senden, um ihn auszuführen. Toolautoren können das Protokoll jedoch auch direkt wie in der PEP beschrieben implementieren, die die zugrunde liegenden Mechanismen für das sichere Anhängen an laufende Prozesse beschreibt.

Die Debugger-Schnittstelle wurde sorgfältig unter Sicherheitsaspekten entworfen und umfasst mehrere Mechanismen zur Zugriffskontrolle

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

Siehe auch

PEP 768.

Eine neue Interpreter-Art

Eine neue Interpreter-Art wurde zu CPython hinzugefügt. Sie verwendet Tail Calls zwischen kleinen C-Funktionen, die einzelne Python-Opcodes implementieren, anstatt einer großen C case-Anweisung. Für bestimmte neuere Compiler bietet dieser Interpreter eine deutlich bessere Leistung. Vorläufige Benchmarks deuten auf eine geometrische Mittelung von 3-5 % schneller auf der Standard-Benchmark-Suite pyperformance hin, abhängig von Plattform und Architektur. Die Basislinie ist Python 3.14, kompiliert mit Clang 19, ohne diesen neuen Interpreter.

Dieser Interpreter funktioniert derzeit nur mit Clang 19 und neueren Versionen auf den Architekturen x86-64 und AArch64. Es wird jedoch erwartet, dass eine zukünftige Version von GCC dies ebenfalls unterstützt.

Diese Funktion ist vorerst opt-in. Die Aktivierung der profilgesteuerten Optimierung (Profile-Guided Optimization) wird bei Verwendung des neuen Interpreters dringend empfohlen, da dies die einzige Konfiguration ist, die auf verbesserte Leistung getestet und validiert wurde. Weitere Informationen finden Sie unter --with-tail-call-interp.

Hinweis

Dies ist nicht zu verwechseln mit der Tail-Call-Optimierung von Python-Funktionen, die derzeit in CPython nicht implementiert ist.

Dieser neue Interpreter-Typ ist ein internes Implementierungsdetail des CPython-Interpreters. Er verändert das sichtbare Verhalten von Python-Programmen überhaupt nicht. Er kann deren Leistung verbessern, aber nichts anderes verändern.

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

Verbesserungen im Free-Threaded-Modus

CPython's Free-Threaded-Modus (PEP 703), der ursprünglich in 3.13 eingeführt wurde, wurde in Python 3.14 erheblich verbessert. Die in PEP 703 beschriebene Implementierung wurde abgeschlossen, einschließlich C-API-Änderungen, und temporäre Workarounds im Interpreter wurden durch dauerhaftere Lösungen ersetzt. Der spezialisierende adaptive Interpreter (PEP 659) ist nun im Free-Threaded-Modus aktiviert, was zusammen mit vielen anderen Optimierungen seine Leistung erheblich verbessert. Die Leistungseinbußen bei Single-Threaded-Code im Free-Threaded-Modus betragen nun etwa 5-10 %, abhängig von der Plattform und dem verwendeten C-Compiler.

Ab Python 3.14 muss beim Kompilieren von Erweiterungsmodulen für den Free-Threaded-Build von CPython unter Windows die Präprozessorvariable Py_GIL_DISABLED vom Build-Backend angegeben werden, da sie nicht mehr automatisch vom C-Compiler bestimmt wird. Für einen laufenden Interpreter kann die zur Kompilierungszeit verwendete Einstellung mithilfe von sysconfig.get_config_var() abgerufen werden.

Das neue Flag -X context_aware_warnings steuert, ob die gleichzeitige sichere Warnungssteuerung aktiviert ist. Das Flag ist standardmäßig auf true für den Free-Threaded-Build und auf false für den GIL-aktivierten Build gesetzt.

Ein neues Flag thread_inherit_context wurde hinzugefügt, das, wenn es aktiviert ist, bedeutet, dass Threads, die mit threading.Thread erstellt werden, mit einer Kopie des Context() des Aufrufers von start() beginnen. Am wichtigsten ist, dass dies den von catch_warnings etablierten Warnungsfilterkontext für Threads (oder asyncio-Aufgaben), die innerhalb dieses Kontexts gestartet werden, „erbt“. Dies wirkt sich auch auf andere Module aus, die Kontextvariablen verwenden, wie z. B. den decimal-Kontextmanager. Dieses Flag ist standardmäßig auf true für den Free-Threaded-Build und auf false für den GIL-aktivierten Build gesetzt.

(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 vielen anderen. Einige dieser Mitwirkenden arbeiten für Meta, das weiterhin erhebliche Ressourcen zur Unterstützung dieses Projekts bereitgestellt hat.)

Verbesserte Fehlermeldungen

  • Der Interpreter liefert nun hilfreiche Vorschläge, wenn Tippfehler in Python-Schlüsselwörtern erkannt werden. Wenn ein Wort gefunden wird, das einem Python-Schlüsselwort stark ähnelt, schlägt der Interpreter das korrekte Schlüsselwort in der Fehlermeldung vor. Diese Funktion hilft Programmierern, häufige Tippfehler schnell zu identifizieren 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'?
    

    Während die Funktion auf die häufigsten Fälle abzielt, können einige Variationen von Tippfehlern immer noch zu normalen Syntaxfehlern führen. (Beigetragen von Pablo Galindo in gh-132449.)

  • elif-Anweisungen, die auf einen else-Block folgen, haben nun eine spezifische 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
    
  • Wenn einer bedingten Auswertung nach else eine Anweisung übergeben wird, oder einem von pass, break oder continue vor if übergeben wird, hebt die Fehlermeldung hervor, wo der Ausdruck erforderlich 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
    
  • Wenn falsch geschlossene Zeichenketten erkannt werden, wird in der Fehlermeldung vorgeschlagen, dass die Zeichenkette möglicherweise Teil des Strings 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?
    
  • Wenn Zeichenketten inkompatible Präfixe haben, zeigt der Fehler nun an, welche Präfixe inkompatibel 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 inkompatiblen Zielen in

    • Imports: import ... as ...

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

    • Except-Handler: except ... as ...

    • Pattern-Match-Fälle: 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 synchrone Context-Manager-Protokoll unterstützt, mit async with statt mit with aufgerufen wird, und umgekehrt für das asynchrone Context-Manager-Protokoll. (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 die Module lzma, bz2, gzip und zlib jeweils erneut exportieren. Die neuen Importnamen unter compression sind die bevorzugten Namen für den Import dieser Kompressionsmodule ab Python 3.14. Die bestehenden Modulnamen wurden jedoch nicht als veraltet markiert. Jede Deprecation oder Entfernung der bestehenden Kompressionsmodule erfolgt nicht früher als fünf Jahre nach der Veröffentlichung von 3.14.

Das neue Modul compression.zstd bietet Kompressions- und Dekompressions-APIs für das Zstandard-Format über Bindings zur zstd-Bibliothek von Meta. Zstandard ist ein weit verbreitetes, hochgradig effizientes und schnelles Kompressionsformat. Zusätzlich zu den in compression.zstd eingeführten APIs wurde die Unterstützung für das Lesen und Schreiben von Zstandard-komprimierten Archiven zu den Modulen tarfile, zipfile und shutil hinzugefügt.

Hier ist ein Beispiel für die Verwendung des neuen Moduls zum Komprimieren von Daten

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 ersichtlich, ist die API ähnlich zu 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.

Asyncio-Introspektionsfähigkeiten

Eine neue Kommandozeilenschnittstelle zum Untersuchen laufender Python-Prozesse mithilfe von asynchronen Tasks wurde hinzugefügt. Sie ist verfügbar über python -m asyncio ps PID oder python -m asyncio pstree PID.

Der Unterbefehl ps untersucht die angegebene Prozess-ID (PID) und zeigt Informationen über aktuell laufende asyncio-Tasks an. Er gibt eine Task-Tabelle aus: eine flache Liste aller Tasks, ihre Namen, ihre Coroutine-Stacks und welche Tasks auf sie warten.

Der Unterbefehl pstree ruft dieselben Informationen ab, rendert jedoch stattdessen einen visuellen asynchronen Aufrufbaum, der Coroutine-Beziehungen in einem hierarchischen Format anzeigt. Dieses Kommando ist besonders nützlich zum Debuggen von lang laufenden oder blockierten asynchronen Programmen. Es kann Entwicklern helfen, schnell zu identifizieren, wo ein Programm blockiert ist, welche Tasks ausstehen und wie Coroutinen miteinander verkettet sind.

Beispiel für diesen 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())

Die Ausführung des neuen Tools auf dem laufenden Prozess 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

Wenn ein Zyklus im asynchronen await-Graphen erkannt wird (was auf ein Programmierproblem hindeuten könnte), löst das Tool einen Fehler aus und listet die Zykluspfade auf, die die Baumkonstruktion 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.)

Gleichzeitig sichere Warnungskontrolle

Der Kontextmanager warnings.catch_warnings verwendet jetzt optional eine Kontextvariable für Warnfilter. Dies wird durch Setzen des Flags context_aware_warnings aktiviert, entweder mit der Kommandozeilenoption -X oder einer Umgebungsvariablen. Dies ermöglicht eine vorhersagbare Warnungskontrolle bei der Verwendung von catch_warnings in Kombination mit mehreren Threads oder asynchronen Tasks. Das Flag ist standardmäßig wahr für den freien Thread-Build und falsch für den GIL-aktivierten Build.

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

Andere Sprachänderungen

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

  • Implementierung von gemischt-modalen Arithmetikregeln, die reelle und komplexe Zahlen kombinieren, wie sie seit C99 im C-Standard spezifiziert sind. (Beigetragen von Sergey B Kirpichev in gh-69639.)

  • Mehr Syntaxfehler werden nun unabhängig von der Optimierung und der Kommandozeilenoption -O erkannt. Dies umfasst Zuweisungen an __debug__, falsche Verwendung von await und asynchrone Comprehensions außerhalb von asynchronen Funktionen. Zum Beispiel erzeugen python -O -c 'assert (__debug__ := 1)' oder python -O -c 'assert await 1' nun SyntaxErrors. (Beigetragen von Irit Katriel und Jelle Zijlstra in gh-122245 & gh-121637.)

  • Beim Unterklassen eines reinen C-Typs werden die C-Slots für den neuen Typ bei der Klassenerstellung nicht mehr durch eine umhüllte Version ersetzt, wenn sie in der Unterklasse nicht explizit überschrieben werden. (Beigetragen von Tomasz Pytel in gh-132284.)

Built-ins

Kommandozeile und Umgebung

  • Das Flag für die Importzeit kann nun bereits geladene ('gecachedte') Module verfolgen, über das neue -X importtime=2. Wenn ein solches Modul importiert wird, werden die Zeiten self und cumulative durch die Zeichenkette cached ersetzt.

    Werte über 2 für -X importtime sind nun für zukünftige Verwendungen reserviert.

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

  • Die Kommandozeilenoption -c dedentet nun automatisch ihr Code-Argument vor der Ausführung. Das automatische Dedenting spiegelt textwrap.dedent() wider. (Beigetragen von Jon Crall und Steven Sun in gh-103998.)

  • -J ist nicht mehr ein reserviertes Flag für Jython und hat nun keine spezielle Bedeutung mehr. (Beigetragen von Adam Turner in gh-133336.)

PEP 758: Erlauben von except und except* Ausdrücken ohne Klammern

Die Ausdrücke except und except* erlauben nun das Weglassen von Klammern, wenn mehrere Exception-Typen vorhanden sind und die as-Klausel nicht verwendet wird. 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: Kontrollfluss in finally-Blöcken

Der Compiler gibt nun eine SyntaxWarning aus, wenn eine return, break oder continue-Anweisung einen finally-Block verlässt. Diese Änderung ist in PEP 765 spezifiziert.

In Situationen, in denen diese Änderung unpraktisch ist (z. B. wenn die Warnungen aufgrund von Code-Linting redundant sind), kann der Warnfilter verwendet werden, um alle Syntaxwarnungen auszuschalten, indem ignore::SyntaxWarning als Filter hinzugefügt wird. Dies kann in Kombination mit einem Filter, der andere Warnungen in Fehler umwandelt, angegeben werden (z. B. durch Übergabe von -Werror -Wignore::SyntaxWarning als CLI-Optionen oder Setzen von PYTHONWARNINGS=error,ignore::SyntaxWarning).

Beachten Sie, dass das Anwenden eines solchen Filters zur Laufzeit mit dem Modul warnings die Warnung nur in Code unterdrückt, der nachdem der Filter angepasst wurde, kompiliert wird. Code, der vor der Filteranpassung kompiliert wird (z. B. beim Importieren eines Moduls), gibt die Syntaxwarnung weiterhin aus.

(Beigetragen von Irit Katriel in gh-130080.)

Inkrementelle Garbage Collection

Der zyklische Garbage Collector ist nun inkrementell. Das bedeutet, dass die maximalen Pausenzeiten für größere Heaps um eine Größenordnung oder mehr reduziert werden.

Es gibt nun nur noch zwei Generationen: jung und alt. Wenn gc.collect() nicht direkt aufgerufen wird, wird der GC etwas seltener aufgerufen. Wenn er aufgerufen wird, sammelt er die junge Generation und einen Teil der alten Generation, anstatt eine oder mehrere Generationen zu sammeln.

Das Verhalten von gc.collect() ändert sich geringfügig

  • gc.collect(1): Führt eine inkrementelle Garbage Collection durch, anstatt Generation 1 zu sammeln.

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

(Beigetragen von Mark Shannon in gh-108362.)

Standardmäßige interaktive Shell

  • Die standardmäßige interaktive Shell hebt nun die Python-Syntax hervor. Das Feature ist standardmäßig aktiviert, außer wenn PYTHON_BASIC_REPL oder eine andere Umgebungsvariable, die Farbe deaktiviert, gesetzt ist. Weitere Informationen finden Sie unter Farbe steuern.

    Das Standard-Farbschema für die Syntaxhervorhebung strebt einen guten Kontrast an und verwendet ausschließlich die 4-Bit-VGA-Standard-ANSI-Farbcodes für maximale Kompatibilität. Das Thema kann über eine experimentelle API _colorize.set_theme() angepasst werden. Dies kann interaktiv oder im PYTHONSTARTUP-Skript aufgerufen werden. Beachten Sie, dass diese Funktion keine Stabilitätsgarantien hat und sich ändern oder entfernt werden kann.

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

  • Die standardmäßige interaktive Shell unterstützt nun den Import-Auto-Vervollständigung. Das bedeutet, dass das Tippen von import co und Drücken von <Tab> Module vorschlagen wird, die mit co beginnen. Ebenso schlägt das Tippen von from concurrent import i Untermodule von concurrent vor, die mit i beginnen. Beachten Sie, dass die Autovervollständigung von Modulattributen derzeit nicht unterstützt wird. (Beigetragen von Tomas Roun in gh-69605.)

Neue Module

  • annotationlib: Zum Introspektieren von Annotationen. Weitere Details finden Sie unter PEP 749. (Beigetragen von Jelle Zijlstra in gh-119180.)

  • compression (einschließlich compression.zstd): Ein Paket für kompressionsbezogene Module, einschließlich eines neuen Moduls zur Unterstützung des Zstandard-Kompressionsformats. Weitere Details finden Sie 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. Weitere Details finden Sie unter PEP 734. (Beigetragen von Eric Snow in gh-134939.)

  • string.templatelib: Unterstützung für Template-String-Literale (t-Strings). Weitere Details finden Sie 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 nun wider, wie der Python-Interpreter angewiesen wurde, den Code des Moduls __main__ zu finden. (Beigetragen von Serhiy Storchaka und Alyssa Coghlan in gh-66436.)

  • Einführung des optionalen Parameters suggest_on_error für argparse.ArgumentParser, der Vorschläge für Argumentauswahlen und Subparser-Namen ermöglicht, wenn diese vom Benutzer falsch eingegeben wurden. (Beigetragen von Savannah Ostrowski in gh-124456.)

  • Aktivierung der Farbe für Hilfetexte, die mit dem optionalen Parameter color für argparse.ArgumentParser deaktiviert werden kann. Dies kann auch über Umgebungsvariablen gesteuert werden. (Beigetragen von Hugo van Kemenade in gh-130645.)

ast

  • Hinzufügen von compare(), einer Funktion zum Vergleichen zweier ASTs. (Beigetragen von Batuhan Taskaya und Jeremy Hylton in gh-60191.)

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

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

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

  • Wenn die Funktion parse() mit einem AST als Eingabe aufgerufen wird, überprüft sie nun immer, ob der Typ des Wurzelknotens angemessen ist. (Beigetragen von Irit Katriel in gh-130139.)

  • Hinzufügen neuer Optionen zur Kommandozeilenschnittstelle: --feature-version, --optimize und --show-empty. (Beigetragen von Semyon Moroz in gh-133367.)

asyncio

  • Die Funktionen und Methoden mit dem Namen create_task() akzeptieren nun eine beliebige Liste von Schlüsselwortargumenten. Alle Schlüsselwortargumente werden an den Task-Konstruktor oder die benutzerdefinierte Task-Fabrik übergeben. (Details finden Sie unter set_task_factory().) Die Schlüsselwortargumente name und context sind nicht mehr speziell; der Name sollte nun über das Schlüsselwortargument name der Fabrik gesetzt werden, und context kann None sein.

    Dies betrifft die folgenden Funktionen und Methoden: asyncio.create_task(), asyncio.loop.create_task(), asyncio.TaskGroup.create_task().

    (Beigetragen von Thomas Grainger in gh-128307.)

  • Es gibt zwei neue Dienstprogramme zur Introspektion und zum Drucken des Aufrufdiagramms eines Programms: capture_call_graph() und print_call_graph(). Weitere Details finden Sie unter Asyncio-Introspektionsfähigkeiten. (Beigetragen von Yury Selivanov, Pablo Galindo Salgado und Łukasz Langa in gh-91048.)

calendar

  • Standardmäßig wird das heutige Datum in der Textausgabe der calendar-Befehlszeile farblich hervorgehoben. Dies kann über Umgebungsvariablen gesteuert werden. (Beigetragen von Hugo van Kemenade in gh-128317.)

concurrent.futures

  • Hinzufügen einer neuen Executor-Klasse, InterpreterPoolExecutor, die mehrere Python-Interpreter im selben Prozess ('Subinterpreters') für Python-Code verfügbar macht. Dies verwendet einen Pool von unabhängigen Python-Interpretern, um Aufrufe asynchron auszuführen.

    Dies ist getrennt von dem neuen Modul interpreters, das durch PEP 734 eingeführt wurde. (Beigetragen von Eric Snow in gh-124548.)

  • Auf Unix-Plattformen außer macOS ist ‘forkserver’ nun die Standard-Startmethode start method für ProcessPoolExecutor (ersetzt ‘fork’). Diese Änderung betrifft nicht Windows oder macOS, wo ‘spawn’ weiterhin die Standard-Startmethode ist.

    Wenn die Threading-inkompatible fork-Methode erforderlich ist, muss sie explizit angefordert werden, indem ein Multiprocessing-Kontext mp_context an ProcessPoolExecutor übergeben wird.

    Siehe forkserver-Beschränkungen für Informationen und Unterschiede zur fork-Methode und wie diese Änderung bestehenden Code mit veränderlichen globalen gemeinsam genutzten Variablen und/oder gemeinsam genutzten Objekten, die nicht automatisch gepickelt werden können, beeinflussen könnte.

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

  • Hinzufügen von zwei neuen Methoden zu ProcessPoolExecutor, terminate_workers() und kill_workers(), als Möglichkeiten, alle lebenden Worker-Prozesse im angegebenen Pool zu beenden oder zu töten. (Beigetragen von Charles Machalow in gh-130849.)

  • Hinzufügen des optionalen Parameters buffersize zu Executor.map, um die Anzahl der übermittelten Tasks zu begrenzen, deren Ergebnisse noch nicht zurückgegeben wurden. Wenn der Puffer voll ist, pausiert die Iteration über die iterables, bis ein Ergebnis aus dem Puffer zurückgegeben wird. (Beigetragen von Enzo Bonnal und Josh Rosenberg in gh-74028.)

configparser

  • configparser schreibt nun keine Konfigurationsdateien mehr, die es nicht lesen kann, um die Sicherheit zu verbessern. Der Versuch, Schlüssel zu schreiben, die Trennzeichen enthalten oder mit dem Abschnittsheader-Muster beginnen, löst einen InvalidWriteError aus. (Beigetragen von Jacob Lincoln in gh-129270.)

contextvars

ctypes

  • Das Layout von Bitfeldern in Structure- und Union-Objekten entspricht nun stärker den plattformspezifischen Standardeinstellungen (GCC/Clang oder MSVC). Insbesondere überlappen sich Felder nicht mehr. (Beigetragen von Matthias Görgens in gh-97702.)

  • Das Klassenattribut Structure._layout_ kann nun gesetzt werden, um eine nicht standardmäßige ABI abzugleichen. (Beigetragen von Petr Viktorin in gh-97702.)

  • Die Klasse der Deskriptoren für Structure/Union-Felder ist nun als CField verfügbar und verfügt über neue Attribute zur Unterstützung von Debugging und Introspektion. (Beigetragen von Petr Viktorin in gh-128715.)

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

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

  • Hinzufügen von memoryview_at(), einer Funktion zum Erstellen eines memoryview-Objekts, das auf den bereitgestellten Zeiger und die Länge verweist. Dies funktioniert wie ctypes.string_at(), vermeidet jedoch eine Pufferkopie und ist typischerweise nützlich bei der Implementierung von reinen Python-Callback-Funktionen, denen dynamisch große Puffer übergeben werden. (Beigetragen von Rian Hunter in gh-112018.)

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

  • Hinzufügen von ctypes.util.dllist() zum Auflisten der vom aktuellen Prozess geladenen Shared Libraries. (Beigetragen von Brian Ward in gh-119349.)

  • Verschieben des Caches für ctypes.POINTER()-Typen von einem globalen internen Cache (_pointer_type_cache) zum Attribut _CData.__pointer_type__ der entsprechenden ctypes-Typen. Dies verhindert, dass der Cache in einigen Situationen unbegrenzt wächst. (Beigetragen von Sergey Miryanov in gh-100926.)

  • Der py_object-Typ unterstützt nun die Abonnementfunktion und ist somit ein generischer Typ. (Beigetragen von Brian Schubert in gh-132168.)

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

curses

datetime

decimal

  • Hinzufügen von Decimal.from_number() als alternativem Konstruktor für Decimal. (Beigetragen von Serhiy Storchaka in gh-121798.)

  • Exponieren von IEEEContext() zur Unterstützung der Erstellung von Kontexten, die den IEEE 754 (2008) Dezimal-Austauschformaten entsprechen. (Beigetragen von Sergey B Kirpichev in gh-53032.)

difflib

  • Vergleichsseiten mit hervorgehobenen Änderungen, die von der Klasse HtmlDiff generiert werden, unterstützen nun den „Dark Mode“. (Beigetragen von Jiahao Li in gh-129939.)

dis

errno

  • Hinzufügen der Konstante für den Fehlercode EHWPOISON. (Beigetragen von James Roy in gh-126585.)

faulthandler

fnmatch

  • Hinzufügen von filterfalse(), einer Funktion zum Ablehnen von Namen, die einem bestimmten Muster entsprechen. (Beigetragen von Bénédikt Tran in gh-74598.)

fractions

  • Ein Fraction-Objekt kann nun aus jedem Objekt mit der Methode as_integer_ratio() konstruiert werden. (Beigetragen von Serhiy Storchaka in gh-82017.)

  • Hinzufügen von Fraction.from_number() als alternativem Konstruktor für Fraction. (Beigetragen von Serhiy Storchaka in gh-121797.)

functools

  • Hinzufügen des Sentinels Placeholder. Dieser kann mit den Funktionen partial() oder partialmethod() verwendet werden, um einen Platz für Positionsargumente im zurückgegebenen Partial-Objekt zu reservieren. (Beigetragen von Dominykas Grigonis in gh-119127.)

  • Erlauben der Übergabe des initial-Parameters von reduce() als Schlüsselwortargument. (Beigetragen von Sayandip Dutta in gh-125916.)

getopt

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

  • Unterstützung für die Rückgabe von gemischten Optionen und Nicht-Options-Argumenten in der Reihenfolge hinzugefügt. (Beigetragen von Serhiy Storchaka in gh-126390.)

getpass

  • Unterstützung für Tastatur-Feedback in der Funktion getpass() über das nur-Schlüsselwort-Argument echo_char hinzugefügt. Platzhalterzeichen werden bei jeder Eingabe eines Zeichens gerendert und beim Löschen eines Zeichens entfernt. (Beigetragen von Semyon Moroz in gh-77065.)

graphlib

heapq

hmac

  • Eine native Implementierung für HMAC (RFC 2104) unter Verwendung von formal verifiziertem Code aus dem HACL*-Projekt hinzugefügt. Diese Implementierung wird als Fallback verwendet, wenn die OpenSSL-Implementierung von HMAC nicht verfügbar ist. (Beigetragen von Bénédikt Tran in gh-99108.)

http

  • Verzeichnislisten und Fehlerseiten, die vom Modul http.server generiert werden, erlauben es dem Browser, seinen Standard-Dark-Mode anzuwenden. (Beigetragen von Yorik Hansen in gh-123430.)

  • Das Modul http.server unterstützt nun das Servieren über HTTPS mit der Klasse http.server.HTTPSServer. Diese Funktionalität wird über die Kommandozeile (python -m http.server) über die folgenden Optionen verfügbar gemacht

    (Beigetragen von Semyon Moroz in gh-85162.)

imaplib

inspect

  • signature() nimmt ein neues Argument annotation_format entgegen, 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 entgegen. Wenn dies wahr ist, werden Zeichenketten-Annotationen ohne umgebende Anführungszeichen angezeigt. (Beigetragen von Jelle Zijlstra in gh-101552.)

  • Hinzufügen der Funktion ispackage(), um festzustellen, ob ein Objekt ein Paket ist oder nicht. (Beigetragen von Zhikang Yan in gh-125634.)

io

json

linecache

  • getline() kann nun Quellcode für eingefrorene Module abrufen. (Beigetragen von Tian Gao in gh-131638.)

logging.handlers

math

  • Detailliertere Fehlermeldungen für Domänenfehler im Modul hinzugefügt. (Beigetragen von Charlie Zhao und Sergey B Kirpichev in gh-101410.)

mimetypes

  • Hinzufügen einer öffentlichen Kommandozeile für das Modul, aufgerufen über python -m mimetypes. (Beigetragen von Oleg Iarygin und Hugo van Kemenade in gh-93096.)

  • Hinzufügen mehrerer neuer MIME-Typen basierend auf RFCs und gängiger Verwendung

    Microsoft- und RFC 8081-MIME-Typen 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

    RFC 9559-MIME-Typen für Matroska-Containerstrukturen für audiovisuelle Daten

    • Audio ohne Video: audio/matroska (.mka)

    • Video: video/matroska (.mkv)

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

    Bilder mit RFCs

    • RFC 1494: CCITT Group 3 (.g3)

    • RFC 3362: Real-time Facsimile, T.38 (.t38)

    • RFC 3745: JPEG 2000 (.jp2), Erweiterung (.jpx) und Verbund (.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 MIME-Typ-Ergänzungen und -Änderungen

    • RFC 2361: Änderung des Typs für .avi zu video/vnd.avi und für .wav zu audio/vnd.wave

    • RFC 4337: Hinzufügen von MPEG-4 audio/mp4 (.m4a)

    • RFC 5334: Hinzufügen von Ogg-Medien (.oga, .ogg und .ogx)

    • RFC 6713: Hinzufügen von gzip application/gzip (.gz)

    • RFC 9639: Hinzufügen von FLAC audio/flac (.flac)

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

    • Hinzufügen von 7z application/x-7z-compressed (.7z)

    • Hinzufügen von Android-Paket application/vnd.android.package-archive (.apk) wenn nicht streng

    • Hinzufügen von deb application/x-debian-package (.deb)

    • Hinzufügen von glTF-Binärdaten model/gltf-binary (.glb)

    • Hinzufügen von glTF JSON/ASCII model/gltf+json (.gltf)

    • Hinzufügen von M4V video/x-m4v (.m4v)

    • Hinzufügen von PHP application/x-httpd-php (.php)

    • Hinzufügen von RAR application/vnd.rar (.rar)

    • Hinzufügen von RPM application/x-rpm (.rpm)

    • Hinzufügen von STL model/stl (.stl)

    • Hinzufügen von Windows Media Video video/x-ms-wmv (.wmv)

    • De facto: Hinzufügen von WebM audio/webm (.weba)

    • ECMA-376: Hinzufügen der Typen .docx, .pptx und .xlsx

    • OASIS: Hinzufügen der Typen OpenDocument .odg, .odp, .ods und .odt

    • W3C: Hinzufügen von EPUB application/epub+zip (.epub)

    (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‘ nun die Standard-Startmethode (ersetzt ‚fork‘). Diese Änderung betrifft Windows und macOS nicht, wo ‚spawn‘ weiterhin die Standard-Startmethode ist.

    Wenn die Thread-inkompatible fork-Methode benötigt wird, müssen Sie sie explizit über einen Kontext von get_context() (bevorzugt) anfordern oder den Standardwert über set_start_method() ändern.

    Siehe forkserver-Beschränkungen für Informationen und Unterschiede zur fork-Methode und wie diese Änderung bestehenden Code mit veränderlichen globalen gemeinsam genutzten Variablen und/oder gemeinsam genutzten Objekten, die nicht automatisch gepickelt werden können, beeinflussen könnte.

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

  • Die Startmethode 'forkserver' von multiprocessing authentifiziert nun seinen Steuerungssocket, um nicht ausschließlich auf Dateiberechtigungen angewiesen zu sein, um einzuschränken, welche anderen Prozesse den Forkserver zum Erzeugen von Workern und Ausführen von Code veranlassen könnten. (Beigetragen von Gregory P. Smith für gh-97514.)

  • Die Proxy-Objekte von Multiprocessing für die Typen list und dict erhalten zuvor übersehene fehlende Methoden

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

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

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

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

  • interrupt() zu multiprocessing.Process-Objekten hinzugefügt, was den Kindprozess durch Senden von SIGINT beendet. Dies ermöglicht es finally-Klauseln, einen Stack-Trace für den beendeten Prozess auszugeben. (Beigetragen von Artem Pulkin in gh-131913.)

operator

  • is_none() und is_not_none() als ein Paar von Funktionen hinzugefügt, sodass operator.is_none(obj) äquivalent zu obj is None und operator.is_not_none(obj) äquivalent zu obj is not None ist. (Beigetragen von Raymond Hettinger und Nico Mexis in gh-115808.)

os

os.path

  • Der Parameter strict zu realpath() akzeptiert einen neuen Wert, ALLOW_MISSING. Wenn verwendet, werden andere Fehler als FileNotFoundError erneut ausgelöst; der resultierende Pfad kann fehlen, ist aber frei von Symlinks. (Beigetragen von Petr Viktorin für CVE 2025-4517.)

pathlib

  • Methoden zu pathlib.Path hinzugefügt, 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 hinzugefügt, das ein Objekt speichert, das das neue Protokoll pathlib.types.PathInfo implementiert. Das Objekt unterstützt die Abfrage des Dateityps und das interne Caching von Ergebnissen von stat(). Pfadobjekte, die von iterdir() generiert werden, werden mit Dateitypinformationen initialisiert, die aus dem Scannen des übergeordneten Verzeichnisses gewonnen wurden. (Beigetragen von Barney Gale in gh-125413.)

pdb

  • Das Modul pdb unterstützt nun das Remotedebugging eines laufenden Python-Prozesses mit der neuen Kommandozeilenoption -p PID.

    python -m pdb -p 1234
    

    Dies verbindet sich mit dem Python-Prozess mit der angegebenen PID und ermöglicht Ihnen, ihn interaktiv zu debuggen. Beachten Sie, dass aufgrund der Funktionsweise des Python-Interpreters das Anhängen an einen Remote-Prozess, der in einem Systemaufruf blockiert ist oder auf I/O wartet, erst funktioniert, wenn die nächste Bytecode-Anweisung ausgeführt wird oder wenn der Prozess ein Signal empfängt.

    Diese Funktion verwendet PEP 768 und die neue Funktion sys.remote_exec(), um sich an den Remote-Prozess anzuhängen und ihm PDB-Befehle zu senden.

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

  • Fest verdrahtete Breakpoints (breakpoint() und set_trace()) verwenden nun die zuletzt aufgerufene Pdb-Instanz wieder, die set_trace() aufruft, anstatt jedes Mal eine neue zu erstellen. Infolgedessen bleiben alle instanzspezifischen Daten wie display und commands über fest verdrahtete Breakpoints hinweg erhalten. (Beigetragen von Tian Gao in gh-121450.)

  • Ein neues Argument mode zu pdb.Pdb hinzugefügt. Der Befehl restart wird deaktiviert, wenn pdb im Modus inline ist. (Beigetragen von Tian Gao in gh-123757.)

  • Eine Bestätigungsaufforderung wird angezeigt, wenn der Benutzer versucht, pdb im Modus inline zu beenden. y, Y, <Enter> oder EOF bestätigen das Beenden und rufen sys.exit() auf, anstatt bdb.BdbQuit auszulösen. (Beigetragen von Tian Gao in gh-124704.)

  • Inline-Breakpoints wie breakpoint() oder pdb.set_trace() stoppen das Programm immer im aufrufenden Frame und ignorieren dabei das skip-Muster (falls vorhanden). (Beigetragen von Tian Gao in gh-130493.)

  • <tab> am Anfang der Zeile bei der mehrzeiligen Eingabe in pdb füllt nun mit einer Einrückung von 4 Leerzeichen, anstatt ein \t-Zeichen einzufügen. (Beigetragen von Tian Gao in gh-130471.)

  • Auto-Einrückung wird in der mehrzeiligen Eingabe von pdb eingeführt. Sie behält entweder die Einrückung der letzten Zeile bei oder fügt eine Einrückung von 4 Leerzeichen ein, wenn ein neuer Codeblock erkannt wird. (Beigetragen von Tian Gao in gh-133350.)

  • $_asynctask wird hinzugefügt, um auf die aktuelle asyncio-Aufgabe zuzugreifen, falls zutreffend. (Beigetragen von Tian Gao in gh-124367.)

  • pdb.set_trace_async() wird hinzugefügt, um das Debuggen von asyncio-Koroutinen zu unterstützen. await-Anweisungen werden mit dieser Funktion unterstützt. (Beigetragen von Tian Gao in gh-132576.)

  • Der in pdb angezeigte Quellcode wird syntaktisch hervorgehoben. Dieses Feature kann mit denselben Methoden wie die Standard-Shell für interaktive Nutzung gesteuert werden, zusätzlich zum neu hinzugefügten Argument colorize von pdb.Pdb. (Beigetragen von Tian Gao und Łukasz Langa in gh-133355.)

pickle

  • Die Standard-Protokollversion im Modul pickle auf 5 gesetzt. Weitere Details finden Sie unter pickle-Protokolle.

  • Ausnahmehinweise für Pickle-Serialisierungsfehler hinzugefügt, die die Identifizierung der Fehlerquelle ermöglichen. (Beigetragen von Serhiy Storchaka in gh-122213.)

platform

  • Die Funktion invalidate_caches() zum Invalidieren von gecachten Ergebnissen im Modul platform hinzugefügt. (Beigetragen von Bénédikt Tran in gh-122549.)

pydoc

  • Annotationen in der Hilfeausgabe werden jetzt normalerweise in einem Format angezeigt, das näher am Quelltext liegt. (Beigetragen von Jelle Zijlstra in gh-101552.)

re

  • \z als Synonym für \Z in regulären Ausdrücken unterstützt. Es wird in vielen anderen regulären Ausdrucks-Engines eindeutig interpretiert, im Gegensatz zu \Z, das ein subtil anderes Verhalten hat. (Beigetragen von Serhiy Storchaka in gh-133306.)

  • \B in regulären Ausdrücken stimmt nun mit dem leeren Eingabe-String überein, was bedeutet, dass es nun immer das Gegenteil von \b ist. (Beigetragen von Serhiy Storchaka in gh-124130.)

socket

  • Unterstützung für Bluetooth-Sockets verbessert und korrigiert.

    • Unterstützung für Bluetooth-Sockets auf NetBSD und DragonFly BSD korrigiert. (Beigetragen von Serhiy Storchaka in gh-132429.)

    • Unterstützung für BTPROTO_HCI auf FreeBSD korrigiert. (Beigetragen von Victor Stinner in gh-111178.)

    • Unterstützung für BTPROTO_SCO auf FreeBSD hinzugefügt. (Beigetragen von Serhiy Storchaka in gh-85302.)

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

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

    • Akzeptiert eine Ganzzahl als Adresse für BTPROTO_HCI unter Linux. (Beigetragen von Serhiy Storchaka in gh-132099.)

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

    • Viele neue Konstanten hinzugefügt. (Beigetragen von Serhiy Storchaka in gh-132734.)

ssl

  • Die boolesche Variable HAS_PHA gibt an, ob das Modul ssl die TLSv1.3 Post-Handshake-Client-Authentifizierung (PHA) unterstützt. (Beigetragen von Will Childs-Klein in gh-128036.)

struct

  • Unterstützung für die C-Typen float complex und double complex im Modul struct (Formatierungszeichen 'F' bzw. 'D'). (Beigetragen von Sergey B Kirpichev in gh-121249.)

symtable

sys

  • Die zuvor undokumentierte spezielle Funktion sys.getobjects(), die nur in spezialisierten Python-Builds existiert, kann nun Objekte aus anderen Interpretern als dem aufgerufenen zurückgeben. (Beigetragen von Eric Snow in gh-125286.)

  • sys._is_immortal() zum Ermitteln, ob ein Objekt unsterblich ist, hinzugefügt. (Beigetragen von Peter Bierma in gh-128509.)

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

  • Löst DeprecationWarning für sys._clear_type_cache() aus. Diese Funktion wurde in Python 3.13 als veraltet markiert, hat aber keine Laufzeitwarnung ausgelöst.

  • sys.remote_exec() zum Implementieren der neuen externen Debugger-Schnittstelle hinzugefügt. Siehe PEP 768 für Details. (Beigetragen von Pablo Galindo Salgado, Matt Wozniski und Ivona Stojanovic in gh-131591.)

  • Der Namespace sys._jit mit Dienstprogrammen zur Introspektion von Just-in-Time-Kompilierung hinzugefügt. (Beigetragen von Brandt Bucher in gh-133231.)

sys.monitoring

  • Zwei neue Monitoring-Events, BRANCH_LEFT und BRANCH_RIGHT, hinzugefügt. Diese ersetzen und veralten das Event BRANCH. (Beigetragen von Mark Shannon in gh-122548.)

sysconfig

tarfile

threading

tkinter

  • Die Methoden after() und after_idle() von tkinter-Widgets akzeptieren nun Schlüsselwortargumente. (Beigetragen von Zhikang Yan in gh-126899.)

  • Fügt die Möglichkeit hinzu, einen Namen für tkinter.OptionMenu und tkinter.ttk.OptionMenu zu spezifizieren. (Beigetragen von Zhikang Yan in gh-130482.)

turtle

types

typing

  • Die Typen types.UnionType und typing.Union sind nun Aliase füreinander. Das bedeutet, dass sowohl alte Unions (erstellt mit Union[int, str]) als auch neue Unions (int | str) nun Instanzen desselben Laufzeittyps erzeugen. Dies vereinheitlicht das Verhalten zwischen den beiden Syntaxen, führt aber zu einigen Verhaltensunterschieden, die Benutzer beeinträchtigen können, die Typen zur Laufzeit introspektieren.

    • Beide Syntaxen zur Erstellung einer Union erzeugen nun dieselbe String-Repräsentation in repr(). Zum Beispiel ist repr(Union[int, str]) nun "int | str" anstelle von "typing.Union[int, str]".

    • Unions, die mit der alten Syntax erstellt wurden, werden nicht mehr zwischengespeichert. Zuvor gab die mehrfache Ausführung von Union[int, str] dasselbe Objekt zurück (Union[int, str] is Union[int, str] wäre True), nun werden jedoch zwei verschiedene Objekte zurückgegeben. Verwenden Sie ==, um Unions auf Gleichheit zu vergleichen, nicht is. Neue Unions wurden nie auf diese Weise zwischengespeichert. Diese Änderung kann die Speichernutzung einiger Programme erhöhen, die eine große Anzahl von Unions verwenden, die durch Subskription von typing.Union erstellt werden. Mehrere Faktoren gleichen diese Kosten jedoch aus: Unions, die in Annotationen verwendet werden, werden in Python 3.14 aufgrund von PEP 649 standardmäßig nicht mehr ausgewertet; eine Instanz von types.UnionType ist selbst viel kleiner als das Objekt, das von Union[] in früheren Python-Versionen zurückgegeben wurde; und die Entfernung des Caches spart ebenfalls etwas Platz. Es ist daher unwahrscheinlich, dass diese Änderung bei den meisten Benutzern zu einem signifikanten Anstieg der Speichernutzung führt.

    • Zuvor wurden alte Unions mithilfe der privaten Klasse typing._UnionGenericAlias implementiert. Diese Klasse wird für die Implementierung nicht mehr benötigt, wurde jedoch zur Abwärtskompatibilität beibehalten, wobei die Entfernung für Python 3.17 geplant ist. Benutzer sollten dokumentierte Introspektionshelfer wie get_origin() und typing.get_args() verwenden, anstatt sich auf private Implementierungsdetails zu verlassen.

    • Es ist nun möglich, typing.Union selbst in isinstance()-Prüfungen zu verwenden. Zum Beispiel gibt isinstance(int | str, typing.Union) True zurück; zuvor wurde ein TypeError ausgelöst.

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

    • Es ist nicht mehr möglich, beliebige Attribute auf Union-Objekten zu setzen. Dies funktionierte in früheren Versionen nur für Dunder-Attribute, war nie dokumentiert und war in vielen Fällen subtil fehlerhaft.

    (Beigetragen von Jelle Zijlstra in gh-105499.)

  • TypeAliasType unterstützt nun Stern-Entpackung.

unicodedata

  • Die Unicode-Datenbank wurde auf Unicode 16.0.0 aktualisiert.

unittest

urllib

  • Aktualisiert den HTTP-Digest-Authentifizierungsalgorithmus für urllib.request durch Unterstützung der SHA-256 Digest-Authentifizierung gemäß RFC 7616. (Beigetragen von Calvin Bui in gh-128193.)

  • Verbessert die Ergonomie und die Standardkonformität beim Parsen und Ausgeben von file:-URLs.

    In url2pathname()

    • Akzeptiert eine vollständige URL, wenn das neue Argument require_scheme auf true gesetzt ist.

    • Verwirft die URL-Autorität, wenn sie mit dem lokalen Hostnamen übereinstimmt.

    • Verwirft die URL-Autorität, wenn sie zu einer lokalen IP-Adresse aufgelöst wird, wenn das neue Argument resolve_host auf true gesetzt ist.

    • Verwirft URL-Abfrage- und Fragmentkomponenten.

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

    In pathname2url()

    • Gibt eine vollständige URL zurück, wenn das neue Argument add_scheme auf true gesetzt ist.

    • Schließt eine leere URL-Autorität ein, wenn ein Pfad mit einem Schrägstrich beginnt. Zum Beispiel wird der Pfad /etc/hosts 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

  • Fügt Unterstützung für UUID-Versionen 6, 7 und 8 über uuid6(), uuid7() und uuid8() entsprechend RFC 9562 hinzu. (Beigetragen von Bénédikt Tran in gh-89083.)

  • NIL und MAX sind nun verfügbar, um die Nil- und Max-UUID-Formate gemäß RFC 9562 darzustellen. (Beigetragen von Nick Pope in gh-128427.)

  • Ermöglicht die gleichzeitige Generierung mehrerer UUIDs über die Befehlszeile über python -m uuid --count. (Beigetragen von Simon Legner in gh-131236.)

webbrowser

  • Namen in der Umgebungsvariablen BROWSER können nun auf bereits registrierte Browser für das Modul webbrowser verweisen, anstatt immer einen neuen Browserbefehl zu generieren.

    Dadurch ist es möglich, BROWSER auf den Wert eines der unterstützten Browser unter macOS zu setzen.

zipfile

Optimierungen

asyncio

  • Standard-Benchmarkergebnisse wurden um 10-20% verbessert, nachdem eine neue pro-Thread-doppelt verkettete Liste für native tasks implementiert wurde, was auch den Speicherverbrauch reduzierte. Dies ermöglicht externen Introspektionswerkzeugen wie python -m asyncio pstree die Introspektion des Aufrufdiagramms von asyncio-Aufgaben, die in allen Threads ausgeführt werden. (Beigetragen von Kumar Aditya in gh-107803.)

  • Das Modul verfügt nun über erstklassige Unterstützung für Free-Threading-Builds. Dies ermöglicht die parallele Ausführung mehrerer Event-Loops über verschiedene Threads hinweg und skaliert linear mit der Anzahl der Threads. (Beigetragen von Kumar Aditya in gh-128002.)

base64

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

bdb

  • Der grundlegende Debugger verfügt nun über ein Backend, das auf sys.monitoring basiert und über die Übergabe von 'monitoring' an den neuen Parameter backend der Klasse Bdb ausgewählt werden kann. (Beigetragen von Tian Gao in gh-124533.)

difflib

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

gc

  • Der neue inkrementelle Garbage Collector bedeutet, dass die maximalen Pausenzeiten für größere Heaps um eine oder mehrere Größenordnungen reduziert werden.

    Aufgrund dieser Optimierung haben sich die Bedeutung der Ergebnisse von get_threshold() und set_threshold() geändert, ebenso wie bei get_count() und get_stats().

    • Aus Kompatibilitätsgründen gibt get_threshold() weiterhin ein Tupel mit drei Elementen zurück. Der erste Wert ist die Schwelle für junge Sammlungen, wie zuvor; der zweite Wert bestimmt die Rate, mit der die alte Sammlung gescannt wird (der Standardwert ist 10, und höhere Werte bedeuten, dass die alte Sammlung langsamer gescannt wird). Der dritte Wert ist nun bedeutungslos und immer null.

    • set_threshold() ignoriert nun alle Elemente nach dem zweiten.

    • get_count() und get_stats() geben weiterhin dasselbe Format von Ergebnissen zurück. Der einzige Unterschied besteht darin, dass sich die Ergebnisse nicht mehr auf die jungen, alternden und alten Generationen beziehen, sondern auf die junge Generation und die alternden und sammelnden Bereiche der alten Generation.

    Zusammenfassend lässt sich sagen, dass Code, der versuchte, das Verhalten des Zyklus-GC zu manipulieren, möglicherweise nicht genau wie erwartet funktioniert, aber es ist sehr unwahrscheinlich, dass er schädlich ist. Jeglicher anderer Code funktioniert einwandfrei.

    (Beigetragen von Mark Shannon in gh-108362.)

io

  • Das Öffnen und Lesen von Dateien erfordert nun weniger Systemaufrufe. Das Lesen einer kleinen, vom Betriebssystem zwischengespeicherten Datei ist bis zu 15 % schneller. (Beigetragen von Cody Maloney und Victor Stinner in gh-120754 und gh-90102.)

pathlib

  • Path.read_bytes verwendet nun den unbuffered-Modus zum Öffnen von Dateien, was beim vollständigen Lesen zwischen 9 % und 17 % schneller ist. (Beigetragen von Cody Maloney in gh-120754.)

pdb

uuid

  • uuid3() und uuid5() sind nun beide ungefähr 40 % schneller für 16-Byte-Namen und 20 % schneller für 1024-Byte-Namen. Die Leistung für längere Namen bleibt unverändert. (Beigetragen von Bénédikt Tran in gh-128150.)

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

zlib

  • Unter Windows wird zlib-ng als Implementierung des Moduls zlib in den Standard-Binärdateien verwendet. Es gibt keine bekannten Inkompatibilitäten zwischen zlib-ng und der zuvor verwendeten zlib-Implementierung. Dies sollte zu einer besseren Leistung bei allen Kompressionsstufen führen.

    Es ist erwähnenswert, dass zlib.Z_BEST_SPEED (1) zu einer deutlich geringeren Kompression als die vorherige Implementierung führen kann und gleichzeitig die Kompressionszeit erheblich verkürzt.

    (Beigetragen von Steve Dower in gh-91349.)

Entfernt

argparse

  • Entfernt die Parameter type, choices und metavar von BooleanOptionalAction. Diese sind seit Python 3.12 veraltet. (Beigetragen von Nikita Sobolev in gh-118805.)

  • Das Aufrufen von add_argument_group() für eine Argumentengruppe löst nun einen ValueError aus. Ebenso lösen add_argument_group() oder add_mutually_exclusive_group() für eine gegenseitig exklusive Gruppe nun beide ValueError aus. Dieses „Verschachteln“ wurde nie unterstützt, funktionierte oft nicht richtig und wurde unbeabsichtigt durch Vererbung offengelegt. Diese Funktionalität ist seit Python 3.11 veraltet. (Beigetragen von Savannah Ostrowski in gh-127186.)

ast

  • Entfernt die folgenden Klassen, die seit Python 3.8 veraltete Aliase von Constant waren und seit Python 3.12 Deprecation-Warnungen ausgegeben haben:

    • Bytes

    • Ellipsis

    • NameConstant

    • Num

    • Str

    Als Konsequenz dieser Entfernungen werden benutzerdefinierte Methoden visit_Num, visit_Str, visit_Bytes, visit_NameConstant und visit_Ellipsis für benutzerdefinierte NodeVisitor-Unterklassen nicht mehr aufgerufen, wenn die NodeVisitor-Unterklasse einen AST besucht. Definieren Sie stattdessen eine Methode visit_Constant.

    (Beigetragen von Alex Waygood in gh-119562.)

  • Entfernen Sie die folgenden veralteten Eigenschaften von ast.Constant, die zur Kompatibilität mit den jetzt entfernten AST-Klassen vorhanden waren

    • Constant.n

    • Constant.s

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

asyncio

  • Entfernen Sie die folgenden Klassen, Methoden und Funktionen, die seit Python 3.12 veraltet sind

    • 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 eine RuntimeError aus, wenn keine aktuelle Ereignisschleife vorhanden ist, und erstellt keine Ereignisschleife mehr implizit.

    (Beigetragen von Kumar Aditya in gh-126353.)

    Es gibt ein paar Muster, die asyncio.get_event_loop() verwenden, die meisten davon können durch asyncio.run() ersetzt werden.

    Wenn Sie eine asynchrone Funktion ausführen, verwenden Sie 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 Sie etwas starten müssen, zum Beispiel einen Server, der auf einem Socket lauscht, und dann für immer laufen lassen, verwenden Sie 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 Sie etwas in einer Ereignisschleife ausführen und dann blockierenden Code darum herum ausführen müssen, verwenden Sie 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

  • Entfernen Sie den Parameter isdst von email.utils.localtime(), der seit Python 3.12 veraltet war und ignoriert wurde. (Beigetragen von Hugo van Kemenade in gh-118798.)

importlib.abc

itertools

  • Unterstützung für Kopier-, Tiefkopier- und Pickle-Operationen von itertools-Iteratoren entfernt. Diese haben seit Python 3.12 eine DeprecationWarning ausgegeben. (Beigetragen von Raymond Hettinger in gh-101588.)

pathlib

  • Unterstützung für die Übergabe zusätzlicher Schlüsselwortargumente an Path entfernt. In früheren Versionen wurden solche Argumente ignoriert. (Beigetragen von Barney Gale in gh-74033.)

  • Unterstützung für die Übergabe zusätzlicher Positionsargumente an PurePath.relative_to() und is_relative_to() entfernt. In früheren Versionen wurden solche Argumente an other angehängt. (Beigetragen von Barney Gale in gh-78707.)

pkgutil

  • Entfernen Sie die Funktionen get_loader() und find_loader(), die seit Python 3.12 veraltet sind. (Beigetragen von Bénédikt Tran in gh-97850.)

pty

  • Entfernen Sie die Funktionen master_open() und slave_open(), die seit Python 3.12 veraltet sind. Verwenden Sie stattdessen pty.openpty(). (Beigetragen von Nikita Sobolev in gh-118824.)

sqlite3

  • Entfernen Sie version und version_info aus dem sqlite3-Modul; verwenden Sie sqlite_version und sqlite_version_info für die tatsächliche Versionsnummer der Laufzeit-SQLite-Bibliothek. (Beigetragen von Hugo van Kemenade in gh-118924.)

  • Die Verwendung einer Sequenz von Parametern mit benannten Platzhaltern löst jetzt einen ProgrammingError aus, was seit Python 3.12 veraltet ist. (Beigetragen von Erlend E. Aasland in gh-118928 und gh-101693.)

urllib

  • Entfernen Sie die Klasse Quoter aus urllib.parse, die seit Python 3.11 veraltet ist. (Beigetragen von Nikita Sobolev in gh-118827.)

  • Entfernen Sie die Klassen URLopener und FancyURLopener aus urllib.request, die seit Python 3.3 veraltet sind.

    myopener.open() kann durch urlopen() ersetzt werden. myopener.retrieve() kann durch urlretrieve() ersetzt werden. Anpassungen der Opener-Klassen können durch Übergabe angepasster Handler an build_opener() vorgenommen werden. (Beigetragen von Barney Gale in gh-84850.)

Veraltet

Neue Veralterungen

  • Die Übergabe einer komplexen Zahl als Argument real oder imag im Konstruktor complex() ist jetzt veraltet; komplexe Zahlen sollten nur als einzelnes Positionsargument übergeben werden. (Beigetragen von Serhiy Storchaka in gh-109218.)

  • argparse:

    • Die Übergabe des undokumentierten Schlüsselwortarguments prefix_chars an die Methode add_argument_group() ist jetzt veraltet. (Beigetragen von Savannah Ostrowski in gh-125563.)

    • Der Typkonverter argparse.FileType ist veraltet. Alles, was mit Ressourcenverwaltung zu tun hat, sollte nach der Analyse der Argumente nachgelagert behandelt werden. (Beigetragen von Serhiy Storchaka in gh-58032.)

  • asyncio:

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

  • ctypes:

    • Auf Nicht-Windows-Plattformen ist die Einstellung von Structure._pack_ zur Verwendung eines MSVC-kompatiblen Standard-Speicherlayouts zugunsten der Einstellung von Structure._layout_ auf 'ms' veraltet und wird in Python 3.19 entfernt. (Beigetragen von Petr Viktorin in gh-131747.)

    • Das Aufrufen von ctypes.POINTER() für einen String ist jetzt veraltet. Verwenden Sie unvollständige Typen für selbstbezügliche Strukturen. Außerdem ist der interne Cache ctypes._pointer_type_cache veraltet. Siehe ctypes.POINTER() für aktualisierte Implementierungsdetails. (Beigetragen von Sergey Myrianov in gh-100926.)

  • functools: Das Aufrufen der Python-Implementierung von functools.reduce() mit function oder sequence als Schlüsselwortargumenten ist jetzt veraltet; die Parameter werden in Python 3.16 positionsgebunden. (Beigetragen von Kirill Podoprigora in gh-121676.)

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

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

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

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

  • pathlib: pathlib.PurePath.as_uri() ist jetzt veraltet und wird in Python 3.19 entfernt. Verwenden Sie stattdessen pathlib.Path.as_uri(). (Beigetragen von Barney Gale in gh-123599.)

  • pdb: Das undokumentierte Attribut pdb.Pdb.curframe_locals ist jetzt eine veraltete schreibgeschützte Eigenschaft, die in einer zukünftigen Version von Python entfernt wird. Der geringe Overhead der dynamischen Zugriffs auf Frame-Lokale, der in Python 3.13 durch PEP 667 hinzugefügt wurde, bedeutet, dass der zuvor in diesem Attribut gespeicherte Verweis auf den Frame-Lokale-Cache nicht mehr benötigt wird. Abgeleitete Debugger sollten in Python 3.13 und späteren Versionen direkt auf pdb.Pdb.curframe.f_locals zugreifen. (Beigetragen von Tian Gao in gh-124369 und gh-125951.)

  • symtable: symtable.Class.get_methods() ist aufgrund mangelnden Interesses veraltet und wird in Python 3.16 entfernt. (Beigetragen von Bénédikt Tran in gh-119698.)

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

  • urllib.parse: Die Akzeptanz von Objekten mit falschen Werten (wie 0 und []), außer leeren Strings, bytes-artigen Objekten und None in parse_qsl() und parse_qs() ist jetzt veraltet. (Beigetragen von Serhiy Storchaka in gh-116897.)

Bevorstehende Entfernung in Python 3.15

  • Das Importsystem

    • Das Setzen von __cached__ für ein Modul, während __spec__.cached nicht gesetzt wird, ist veraltet. In Python 3.15 wird __cached__ vom Import-System oder der Standardbibliothek nicht mehr gesetzt oder berücksichtigt. (gh-97879)

    • Das Setzen von __package__ für ein Modul, während __spec__.parent nicht gesetzt wird, ist veraltet. In Python 3.15 wird __package__ vom Import-System oder der Standardbibliothek nicht mehr gesetzt oder berücksichtigt. (gh-97879)

  • ctypes:

    • Die undokumentierte Funktion ctypes.SetPointerType() ist seit Python 3.13 veraltet.

  • http.server:

    • Der veraltete und selten verwendete CGIHTTPRequestHandler ist seit Python 3.13 veraltet. Es gibt keine direkte Ersetzung. Alles ist besser als CGI zur Schnittstellenbildung eines Webservers mit einem Anfragehandler.

    • Das Flag --cgi für die Befehlszeilenschnittstelle python -m http.server ist seit Python 3.13 veraltet.

  • importlib:

    • Methode load_module(): verwenden Sie stattdessen exec_module().

  • locale:

  • pathlib:

  • platform:

    • java_ver() ist seit Python 3.13 veraltet. Diese Funktion ist nur für die Jython-Unterstützung nützlich, hat eine verwirrende API und ist weitgehend ungetestet.

  • sysconfig:

  • threading:

    • RLock() wird in Python 3.15 keine Argumente mehr annehmen. Die Übergabe von Argumenten ist seit Python 3.14 veraltet, da die Python-Version keine Argumente zulässt, die C-Version jedoch beliebig viele Positions- oder Schlüsselwortargumente zulässt und jedes Argument ignoriert.

  • types:

  • typing:

    • Die undokumentierte Schlüsselwortargument-Syntax für die Erstellung von NamedTuple-Klassen (z.B. Point = NamedTuple("Point", x=int, y=int)) ist seit Python 3.13 veraltet. Verwenden Sie stattdessen die klassenbasierte Syntax oder die funktionale Syntax.

    • Bei Verwendung der funktionalen Syntax von TypedDicts ist das Nicht-Übergeben eines Werts an den Parameter fields (TD = TypedDict("TD")) oder das Übergeben von None (TD = TypedDict("TD", None)) seit Python 3.13 veraltet. Verwenden Sie class TD(TypedDict): pass oder TD = TypedDict("TD", {}), um ein TypedDict mit null Feldern zu erstellen.

    • Die Dekoratorfunktion typing.no_type_check_decorator() ist seit Python 3.13 veraltet. Nach acht Jahren im typing-Modul wurde sie bisher von keinem wichtigen Typ-Checker unterstützt.

  • wave:

  • zipimport:

    • load_module() ist seit Python 3.10 veraltet. Verwenden Sie stattdessen exec_module(). (Beigetragen von Jiahao Li in gh-125746.)

Vorschlag zur Entfernung in Python 3.16

  • Das Importsystem

    • Das Setzen von __loader__ für ein Modul, während gleichzeitig __spec__.loader nicht gesetzt wird, ist veraltet. In Python 3.16 wird __loader__ vom Importsystem und der Standardbibliothek weder gesetzt noch berücksichtigt.

  • array:

    • Der Formatcode 'u' (wchar_t) ist seit Python 3.3 in der Dokumentation und seit Python 3.13 zur Laufzeit veraltet. Verwenden Sie stattdessen den Formatcode 'w' (Py_UCS4) für Unicode-Zeichen.

  • asyncio:

  • builtins:

    • Bitweise Inversion auf booleschen Typen, ~True oder ~False, ist seit Python 3.12 veraltet, da sie überraschende und unintuitive Ergebnisse liefert (-2 und -1). Verwenden Sie stattdessen not x für die logische Negation eines Boole-Wertes. In dem seltenen Fall, dass Sie die bitweise Inversion der zugrunde liegenden Ganzzahl benötigen, konvertieren Sie explizit zu int (~int(x)).

  • functools:

    • Das Aufrufen der Python-Implementierung von functools.reduce() mit function oder sequence als Schlüsselwortargumente ist seit Python 3.14 veraltet.

  • logging:

    Die Unterstützung für benutzerdefinierte Logging-Handler mit dem Argument strm ist veraltet und soll in Python 3.16 entfernt werden. Definieren Sie Handler stattdessen mit dem Argument stream. (Beigetragen von Mariusz Felisiak in gh-115032.)

  • mimetypes:

    • Gültige Erweiterungen beginnen mit einem Punkt oder sind leer für mimetypes.MimeTypes.add_type(). Nicht-punktierte Erweiterungen sind veraltet und lösen in Python 3.16 einen ValueError aus. (Beigetragen von Hugo van Kemenade in gh-75223.)

  • shutil:

    • Die Ausnahme ExecError ist seit Python 3.14 veraltet. Sie wurde seit Python 3.4 von keiner Funktion in shutil verwendet und ist nun ein Alias für RuntimeError.

  • symtable:

  • sys:

    • Die Funktion _enablelegacywindowsfsencoding() ist seit Python 3.13 veraltet. Verwenden Sie stattdessen die Umgebungsvariable PYTHONLEGACYWINDOWSFSENCODING.

  • sysconfig:

    • Die Funktion sysconfig.expand_makefile_vars() ist seit Python 3.14 veraltet. Verwenden Sie stattdessen das Argument vars von sysconfig.get_paths().

  • tarfile:

    • Das undokumentierte und ungenutzte Attribut TarFile.tarfile ist seit Python 3.13 veraltet.

Zur Entfernung vorgesehen in Python 3.17

  • collections.abc:

    • collections.abc.ByteString ist zur Entfernung in Python 3.17 geplant.

      Verwenden Sie isinstance(obj, collections.abc.Buffer), um zur Laufzeit zu prüfen, ob obj das Buffer-Protokoll implementiert. Für die Verwendung in Typ-Annotationen verwenden Sie entweder Buffer oder eine Union, die explizit die von Ihrem Code unterstützten Typen angibt (z. B. bytes | bytearray | memoryview).

      ByteString war ursprünglich als abstrakte Klasse gedacht, die als Obertyp für sowohl bytes als auch bytearray dienen sollte. Da die ABC jedoch nie Methoden hatte, wusste man durch die Prüfung, ob ein Objekt eine Instanz von ByteString war, nie wirklich etwas Nützliches über das Objekt. Andere gängige Puffer-Typen wie memoryview wurden auch nie als Untertypen von ByteString verstanden (weder zur Laufzeit noch von statischen Typ-Prüfern).

      Weitere Details finden Sie in PEP 688. (Beigetragen von Shantanu Jain in gh-91896.)

  • typing:

    • Vor Python 3.14 wurden alte Unions mit der privaten Klasse typing._UnionGenericAlias implementiert. Diese Klasse wird für die Implementierung nicht mehr benötigt, wurde aber aus Kompatibilitätsgründen beibehalten, die Entfernung ist für Python 3.17 geplant. Benutzer sollten dokumentierte Introspektionshelfer wie typing.get_origin() und typing.get_args() verwenden, anstatt sich auf private Implementierungsdetails zu verlassen.

    • typing.ByteString, veraltet seit Python 3.9, ist zur Entfernung in Python 3.17 geplant.

      Verwenden Sie isinstance(obj, collections.abc.Buffer), um zur Laufzeit zu prüfen, ob obj das Buffer-Protokoll implementiert. Für die Verwendung in Typ-Annotationen verwenden Sie entweder Buffer oder eine Union, die explizit die von Ihrem Code unterstützten Typen angibt (z. B. bytes | bytearray | memoryview).

      ByteString war ursprünglich als abstrakte Klasse gedacht, die als Obertyp für sowohl bytes als auch bytearray dienen sollte. Da die ABC jedoch nie Methoden hatte, wusste man durch die Prüfung, ob ein Objekt eine Instanz von ByteString war, nie wirklich etwas Nützliches über das Objekt. Andere gängige Puffer-Typen wie memoryview wurden auch nie als Untertypen von ByteString verstanden (weder zur Laufzeit noch von statischen Typ-Prüfern).

      Weitere Details finden Sie in PEP 688. (Beigetragen von Shantanu Jain in gh-91896.)

Zur Entfernung vorgesehen in Python 3.19

  • ctypes:

    • Implizites Umschalten auf das MSVC-kompatible Struktur-Layout durch Setzen von _pack_, aber nicht von _layout_ auf Nicht-Windows-Plattformen.

Zur Entfernung in zukünftigen Versionen vorgesehen

Die folgenden APIs werden in Zukunft entfernt, obwohl derzeit kein Entfernungsdatum festgelegt ist.

  • argparse:

    • Das Verschachteln von Argumentgruppen und das Verschachteln von gegenseitig ausschließenden Gruppen sind veraltet.

    • Das Übergeben des undokumentierten Schlüsselwortarguments *prefix_chars* an add_argument_group() ist nun veraltet.

    • Der Typkonverter argparse.FileType ist veraltet.

  • builtins:

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

    • Derzeit akzeptiert Python numerische Literale, denen direkt Schlüsselwörter folgen, z. B. 0in x, 1or x, 0if 1else 2. Es erlaubt verwirrende und mehrdeutige Ausdrücke wie [0x1for x in y] (die als [0x1 for x in y] oder [0x1f or x in y] interpretiert werden können). Eine Syntaxwarnung wird ausgegeben, wenn dem numerischen Literal direkt eines der Schlüsselwörter and, else, for, if, in, is und or folgt. In einer zukünftigen Version wird dies zu einem Syntaxfehler geändert. (gh-87999)

    • Unterstützung für die Methode __index__() und __int__(), die einen Nicht-Int-Typ zurückgibt: Diese Methoden müssen eine Instanz einer strikten Unterklasse von int zurückgeben.

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

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

    • Delegation von int() an die Methode __trunc__().

    • Das Übergeben einer komplexen Zahl als Argument *real* oder *imag* im Konstruktor complex() ist nun veraltet; sie sollte nur als einzelnes 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: Verwenden Sie open() anstelle von codecs.open(). (gh-133038)

  • codeobject.co_lnotab: Verwenden Sie stattdessen die Methode codeobject.co_lines().

  • datetime:

    • utcnow(): Verwenden Sie datetime.datetime.now(tz=datetime.UTC).

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

  • gettext: Der Pluralwert muss eine Ganzzahl sein.

  • importlib:

    • Der Parameter *debug_override* von cache_from_source() ist veraltet: Verwenden Sie stattdessen den Parameter *optimization*.

  • importlib.metadata:

    • Schnittstelle für das EntryPoints-Tupel.

    • Implizites None bei Rückgabewerten.

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

  • mailbox: Die Verwendung von StringIO als Eingabe und im Textmodus ist veraltet, verwenden Sie stattdessen BytesIO und den Binärmodus.

  • os: Aufruf von os.register_at_fork() in einem Multithreading-Prozess.

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

  • re: Strengere Regeln werden nun für numerische Gruppenreferenzen und Gruppennamen in regulären Ausdrücken angewendet. Nur eine Sequenz von ASCII-Ziffern wird nun als numerische Referenz akzeptiert. Der Gruppenname in Byte-Mustern und Ersetzungszeichenketten kann nun nur ASCII-Buchstaben, Ziffern und Unterstriche enthalten. (Beigetragen von Serhiy Storchaka in gh-91760.)

  • Module sre_compile, sre_constants und sre_parse.

  • shutil: Der Parameter *onerror* von rmtree() ist in Python 3.12 veraltet; verwenden Sie 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: Verwenden Sie 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

    • threading.Condition.notifyAll(): Verwenden Sie notify_all().

    • threading.Event.isSet(): Verwenden Sie is_set().

    • threading.Thread.isDaemon(), threading.Thread.setDaemon(): Verwenden Sie das Attribut threading.Thread.daemon.

    • threading.Thread.getName(), threading.Thread.setName(): Verwenden Sie das Attribut threading.Thread.name.

    • threading.currentThread(): Verwenden Sie threading.current_thread().

    • threading.activeCount(): Verwenden Sie threading.active_count().

  • 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 gewährleisten, wird bis mindestens Python 3.17 ein Kompatibilitäts-Shim bereitgestellt. (Beigetragen von Jelle Zijlstra in gh-105499.)

  • unittest.IsolatedAsyncioTestCase: Das Zurückgeben eines Werts, der nicht None ist, aus einem Testfall ist veraltet.

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

    • splitattr()

    • splithost()

    • splitnport()

    • splitpasswd()

    • splitport()

    • splitquery()

    • splittag()

    • splittype()

    • splituser()

    • splitvalue()

    • to_bytes()

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

  • xml.etree.ElementTree: Das Testen des Wahrheitswerts eines Element ist veraltet. In einer zukünftigen Version wird es immer True zurückgeben. Bevorzugen Sie explizite Tests wie len(elem) oder elem is not None.

  • sys._clear_type_cache() ist veraltet: Verwenden Sie stattdessen sys._clear_internal_caches().

CPython Bytecode-Änderungen

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

  • Fügen Sie die Opcodes BUILD_INTERPOLATION und BUILD_TEMPLATE hinzu, um neue Instanzen von Interpolation bzw. Template zu erstellen. (Beigetragen von Lysandros Nikolaou und anderen in gh-132661; siehe auch PEP 750: Template strings).

  • Entfernen Sie den Opcode BUILD_CONST_KEY_MAP. Verwenden Sie stattdessen BUILD_MAP. (Beigetragen von Mark Shannon in gh-122160.)

  • Ersetzen Sie den Opcode LOAD_ASSERTION_ERROR durch LOAD_COMMON_CONSTANT und fügen Sie Unterstützung für das Laden von NotImplementedError hinzu.

  • Fügen Sie die Opcodes LOAD_FAST_BORROW und LOAD_FAST_BORROW_LOAD_FAST_BORROW hinzu, um den Overhead für die Referenzzählung zu reduzieren, wenn der Interpreter beweisen kann, dass die Referenz im Frame die auf den Stack geladene Referenz überlebt. (Beigetragen von Matt Page in gh-130704.)

  • Fügen Sie den Opcode LOAD_SMALL_INT hinzu, der eine kleine Ganzzahl gleich dem oparg auf den Stack legt. Der Opcode RETURN_CONST wurde entfernt, da er nicht mehr verwendet wird. (Beigetragen von Mark Shannon in gh-125837.)

  • Fügen Sie die neue Anweisung LOAD_SPECIAL hinzu. Generieren Sie Code für with- und async with-Anweisungen unter Verwendung der neuen Anweisung. Entfernen Sie die Anweisungen BEFORE_WITH und BEFORE_ASYNC_WITH. (Beigetragen von Mark Shannon in gh-120507.)

  • Fügen Sie den Opcode POP_ITER hinzu, um „virtuelle“ Iteratoren zu unterstützen. (Beigetragen von Mark Shannon in gh-132554.)

Pseudo-Instruktionen

  • Fügen Sie die Pseudo-Instruktion ANNOTATIONS_PLACEHOLDER hinzu, um teilweise ausgeführte Modul-Annotationen mit verzögerter Auswertung von Annotationen zu unterstützen. (Beigetragen von Jelle Zijlstra in gh-130907.)

  • Fügen Sie die Pseudo-Instruktion BINARY_OP_EXTEND hinzu, die ein Paar von Funktionen (Guard- und Spezialisierungsfunktionen) ausführt, die über den Inline-Cache zugänglich sind. (Beigetragen von Irit Katriel in gh-100239.)

  • Fügen Sie drei Spezialisierungen für CALL_KW hinzu; CALL_KW_PY für Aufrufe an Python-Funktionen, CALL_KW_BOUND_METHOD für Aufrufe an gebundene Methoden und CALL_KW_NON_PY für alle anderen Aufrufe. (Beigetragen von Mark Shannon in gh-118093.)

  • Fügen Sie die Pseudo-Instruktionen JUMP_IF_TRUE und JUMP_IF_FALSE hinzu, bedingte Sprünge, die den Stack nicht beeinflussen. Ersetzt durch die Sequenz COPY 1, TO_BOOL, POP_JUMP_IF_TRUE/FALSE. (Beigetragen von Irit Katriel in gh-124285.)

  • Fügen Sie die Pseudo-Instruktion LOAD_CONST_MORTAL hinzu. (Beigetragen von Mark Shannon in gh-128685.)

  • Fügen Sie die Pseudo-Instruktion LOAD_CONST_IMMORTAL hinzu, die dasselbe tut wie LOAD_CONST, aber effizienter für unsterbliche Objekte ist. (Beigetragen von Mark Shannon in gh-125837.)

  • Fügen Sie die Pseudo-Instruktion NOT_TAKEN hinzu, die von sys.monitoring verwendet wird, um Verzweigungsereignisse (wie BRANCH_LEFT) aufzuzeichnen. (Beigetragen von Mark Shannon in gh-122548.)

C-API-Änderungen

Python-Konfigurations-C-API

Fügen Sie eine PyInitConfig C API hinzu, um die Python-Initialisierung zu konfigurieren, ohne auf C-Strukturen zurückzugreifen und um in Zukunft ABI-kompatible Änderungen vornehmen zu können.

Vervollständigen Sie die PEP 587 PyConfig C API durch Hinzufügen von PyInitConfig_AddModule(), das zum Hinzufügen eines eingebauten Erweiterungsmoduls verwendet werden kann; eine Funktion, die zuvor als „inittab“ bezeichnet wurde.

Fügen Sie die Funktionen PyConfig_Get() und PyConfig_Set() hinzu, um die aktuelle Laufzeitkonfiguration abzurufen und festzulegen.

PEP 587 „Python Initialization Configuration“ hat alle Möglichkeiten zur Konfiguration der Python-Initialisierung vereinheitlicht. Diese PEP vereinheitlicht auch die Konfiguration der Vorinitialisierung und Initialisierung von Python in einer einzigen API. Darüber hinaus bietet diese PEP nur eine einzige Wahl für das Einbetten von Python anstelle von zwei „Python“- und „Isolated“-Wahlen (PEP 587), um die API weiter zu vereinfachen.

Die untergeordnete PEP 587 PyConfig API steht weiterhin für Anwendungsfälle zur Verfügung, die absichtlich eine engere Kopplung an CPython-Implementierungsdetails aufweisen (z. B. Emulation der vollen Funktionalität der CPython CLI, einschließlich ihrer Konfigurationsmechanismen).

(Beigetragen von Victor Stinner in gh-107954.)

Siehe auch

PEP 741 und PEP 587

Neue Funktionen in der C-API

Änderungen in der Limited C API

Entfernte C-APIs

  • Das Erstellen von immutable types mit veränderlichen Basen wurde in Python 3.12 als veraltet markiert und löst nun einen TypeError aus. (Beigetragen von Nikita Sobolev in gh-119775.)

  • Entfernt das Mitglied PyDictObject.ma_version_tag, das in Python 3.12 als veraltet markiert wurde. Verwenden Sie stattdessen die API PyDict_AddWatcher(). (Beigetragen von Sam Gross in gh-124296.)

  • Entfernt die private Funktion _Py_InitializeMain(). Sie war eine vorläufige API, die in Python 3.8 durch PEP 587 hinzugefügt wurde. (Entfernt von Victor Stinner in gh-129033.)

  • Entfernt die undokumentierten APIs Py_C_RECURSION_LIMIT und PyThreadState.c_recursion_remaining. Diese wurden in 3.13 hinzugefügt und ohne Veralterung entfernt. Verwenden Sie Py_EnterRecursiveCall(), um außer Kontrolle geratene Rekursion in C-Code zu verhindern. (Entfernt von Petr Viktorin in gh-133079, siehe auch gh-130396.)

Als veraltet markierte C-APIs

Zur Entfernung in Python 3.15 vorgemerkt

Entfernung in Python 3.16 geplant

  • Die gebündelte Kopie von libmpdec.

Entfernung in Python 3.18 geplant

Entfernung in zukünftigen Versionen geplant

Die folgenden APIs sind veraltet und werden entfernt, obwohl derzeit kein Datum für ihre Entfernung geplant ist.

Build-Änderungen

  • PEP 776: Emscripten ist jetzt eine offiziell unterstützte Plattform unter Tier 3. Als Teil dieser Bemühungen wurden mehr als 25 Fehler in der Emscripten libc behoben. Emscripten beinhaltet nun Unterstützung für ctypes, termios und fcntl sowie experimentelle Unterstützung für die neue standardmäßige interaktive Shell. (Beigetragen von R. Hood Chatham in gh-127146, gh-127683 und gh-136931.)

  • Offizielle Android-Binär-Releases werden nun auf python.org bereitgestellt.

  • GNU Autoconf 2.72 wird nun benötigt, um configure zu generieren. (Beigetragen von Erlend Aasland in gh-115765.)

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

  • Das Linken mittels #pragma mit python3*.lib kann nun mit Py_NO_LINK_LIB ausgeschaltet werden. (Beigetragen von Jean-Christophe Fillion-Robin in gh-82909.)

  • CPython aktiviert standardmäßig eine Reihe von empfohlenen Compiler-Optionen für verbesserte Sicherheit. Verwenden Sie die --disable-safety configure-Option, um diese zu deaktivieren, oder die --enable-slower-safety configure-Option für eine größere Auswahl an Compiler-Optionen, wenn auch mit Leistungseinbußen.

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

  • Die neue configure Option --with-tail-call-interp kann verwendet werden, um den experimentellen Tail-Call-Interpreter zu aktivieren. Weitere Details finden Sie unter Eine neue Art von Interpreter.

  • Um die neue Unterstützung für Remote-Debugging zu deaktivieren, verwenden Sie die configure-Option --without-remote-debug. Dies kann aus Sicherheitsgründen nützlich sein.

  • iOS- und macOS-Apps können nun so konfiguriert werden, dass stdout und stderr an das Systemprotokoll umgeleitet werden. (Beigetragen von Russell Keith-Magee in gh-127592.)

  • Das iOS-Testbed kann nun Testausgaben streamen, während der Test läuft. Das Testbed kann auch verwendet werden, um die Testsuite von Projekten auszuführen, die nicht CPython sind. (Beigetragen von Russell Keith-Magee in gh-127592.)

build-details.json

Installationen von Python enthalten nun eine neue Datei, build-details.json. Dies ist ein statisches JSON-Dokument, das Build-Details für CPython enthält, um eine Introspektion ohne Ausführung von Code zu ermöglichen. Dies ist hilfreich für Anwendungsfälle wie Python-Launcher, Cross-Kompilierung und so weiter.

build-details.json muss im plattformunabhängigen Standardbibliotheksverzeichnis installiert werden. Dies entspricht dem ‘stdlib’ Installationspfad von sysconfig, der durch Ausführung von sysconfig.get_path('stdlib') ermittelt werden kann.

Siehe auch

PEP 739build-details.json 1.0 – eine statische Beschreibungsdatei für Python-Build-Details

Einstellung von PGP-Signaturen

PGP (Pretty Good Privacy) Signaturen werden für Releases von Python 3.14 und zukünftige Versionen nicht mehr bereitgestellt. Zur Überprüfung von CPython-Artefakten müssen Benutzer Sigstore-Verifizierungsmaterialien verwenden. Releases werden seit Python 3.11 mit Sigstore signiert.

Diese Änderung im Release-Prozess wurde in PEP 761 festgelegt.

Free-threaded Python wird offiziell unterstützt

Der Free-threaded Build von Python wird nun unterstützt und ist nicht mehr experimentell. Dies ist der Beginn von Phase II, in der Free-threaded Python offiziell unterstützt, aber immer noch optional ist.

Das Free-threading-Team ist zuversichtlich, dass das Projekt auf dem richtigen Weg ist und schätzt die anhaltende Hingabe aller, die daran arbeiten, Free-threading für eine breitere Akzeptanz in der Python-Community bereit zu machen.

Mit diesen Empfehlungen und der Annahme dieses PEPs sollte die Python-Entwicklergemeinschaft breit verkünden, dass Free-threading eine unterstützte Option für Python-Builds ist, jetzt und in Zukunft, und dass es nicht ohne einen angemessenen Deprecation-Zeitplan entfernt wird.

Jede Entscheidung zur Umstellung auf Phase III, mit Free-threading als Standard- oder einzigem Build von Python, ist noch unentschieden und hängt von vielen Faktoren ab, sowohl innerhalb von CPython selbst als auch in der Community. Diese Entscheidung liegt in der Zukunft.

Binäre Releases für den experimentellen Just-in-Time (JIT) Compiler

Die offiziellen macOS- und Windows-Release-Binärdateien enthalten nun einen *experimentellen* Just-in-Time (JIT) Compiler. Obwohl er für den Produktionseinsatz **nicht** empfohlen wird, kann er durch Setzen von PYTHON_JIT=1 als Umgebungsvariable getestet werden. Downstream-Source-Builds und Redistributoren können die --enable-experimental-jit=yes-off configure-Option für ein ähnliches Verhalten verwenden.

Der JIT befindet sich in einem frühen Stadium und ist noch in aktiver Entwicklung. Daher kann die typische Performance-Auswirkung der Aktivierung von 10 % langsamer bis 20 % schneller reichen, abhängig von der Arbeitslast. Zum Testen und Bewerten wurde eine Reihe von Introspektionsfunktionen im Namensraum sys._jit bereitgestellt. sys._jit.is_available() kann verwendet werden, um festzustellen, ob die aktuelle ausführbare Datei JIT-Kompilierung unterstützt, während sys._jit.is_enabled() verwendet werden kann, um festzustellen, ob die JIT-Kompilierung für den aktuellen Prozess aktiviert wurde.

Derzeit fehlt die bedeutendste Funktionalität darin, dass native Debugger und Profiler wie gdb und perf nicht in der Lage sind, durch JIT-Frames zu unwinden (Python-Debugger und Profiler wie pdb oder profile funktionieren weiterhin ohne Änderungen). Free-threaded Builds unterstützen keine JIT-Kompilierung.

Bitte melden Sie alle Fehler oder größeren Performance-Regressionen, die Sie feststellen!

Siehe auch

PEP 744

Portierung auf Python 3.14

Dieser Abschnitt listet zuvor beschriebene Änderungen und weitere Fehlerbehebungen auf, die möglicherweise Änderungen an Ihrem Code erfordern.

Änderungen in der Python-API

  • Auf Unix-Plattformen außer macOS ist *forkserver* nun die Standard-Startmethode für multiprocessing und ProcessPoolExecutor, anstelle von *fork*.

    Einzelheiten finden Sie unter (1) und (2).

    Wenn Sie auf NameErrors oder Pickling-Fehler stoßen, die aus multiprocessing oder concurrent.futures resultieren, siehe die Einschränkungen von forkserver.

    Diese Änderung betrifft weder Windows noch macOS, wo ‘spawn’ die Standard-Startmethode bleibt.

  • functools.partial ist nun ein Methoden-Deskriptor. Wickeln Sie ihn in staticmethod() ein, wenn Sie das alte Verhalten beibehalten möchten. (Beigetragen von Serhiy Storchaka und Dominykas Grigonis in gh-121027.)

  • Der Garbage Collector ist jetzt inkrementell, was bedeutet, dass sich das Verhalten von gc.collect() leicht ändert.

    • gc.collect(1): Führt eine inkrementelle Garbage Collection durch, anstatt Generation 1 zu sammeln.

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

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

  • types.UnionType ist nun ein Alias für typing.Union, was zu Verhaltensänderungen führt. Siehe oben für weitere Details. (Beigetragen von Jelle Zijlstra in gh-105499.)

  • Das Laufzeitverhalten von Annotationen hat sich in verschiedenen Aspekten geändert; Details finden Sie oben. Obwohl die meisten Codes, die mit Annotationen interagieren, weiterhin funktionieren sollten, können einige undokumentierte Details anders behandelt werden.

  • Als Teil der Veröffentlichung des mimetypes CLI als öffentlich, beendet es nun mit 1 bei Fehlern statt 0 und mit 2 bei fehlerhaften Kommandozeilenparametern statt 1. Fehlermeldungen werden nun nach stderr ausgegeben.

  • Das Muster \B in regulären Ausdrücken passt nun beim Abgleich eines leeren Strings, wenn er als gesamtes Muster angegeben wird, was zu Verhaltensänderungen führen kann.

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

Änderungen bei Annotationen (PEP 649 und PEP 749)

Dieser Abschnitt enthält Anleitungen zu Änderungen, die möglicherweise an Annotationen oder Python-Code, der mit Annotationen interagiert oder diese introspektiert, vorgenommen werden müssen, aufgrund der Änderungen bezüglich der verzögerten Auswertung von Annotationen.

In den meisten Fällen erfordert funktionierender Code aus älteren Python-Versionen keine Änderungen.

Implikationen für annotierten Code

Wenn Sie Annotationen in Ihrem Code definieren (z. B. für die Verwendung mit einem statischen Typ-Checker), dann sind diese Änderungen wahrscheinlich für Sie nicht relevant: Sie können weiterhin Annotationen auf dieselbe Weise schreiben, wie Sie es mit früheren Python-Versionen getan haben.

Sie werden wahrscheinlich in der Lage sein, Anführungszeichen in Annotationen zu entfernen, die häufig für Vorwärtsreferenzen verwendet werden. Ebenso, wenn Sie from __future__ import annotations verwenden, um die Notwendigkeit, Zeichenketten in Annotationen zu schreiben, zu vermeiden, können Sie diesen Import möglicherweise entfernen, sobald Sie nur noch Python 3.14 und neuere Versionen unterstützen. Wenn Sie sich jedoch auf Drittanbieter-Bibliotheken verlassen, die Annotationen lesen, benötigen diese Bibliotheken möglicherweise Änderungen zur Unterstützung von nicht zitierten Annotationen, bevor sie wie erwartet funktionieren.

Implikationen für Leser von __annotations__

Wenn Ihr Code das Attribut __annotations__ auf Objekten liest, möchten Sie möglicherweise Änderungen vornehmen, um Code zu unterstützen, der die verzögerte Auswertung von Annotationen verwendet. Sie könnten zum Beispiel annotationlib.get_annotations() mit dem FORWARDREF-Format verwenden, so wie es das Modul dataclasses nun tut.

Das externe Paket typing_extensions bietet teilweise Backports einiger Funktionalitäten des Moduls annotationlib, wie z. B. die Enumeration Format und die Funktion get_annotations(). Diese können verwendet werden, um versionsübergreifenden Code zu schreiben, der das neue Verhalten in Python 3.14 nutzt.

from __future__ import annotations

In Python 3.7 führte PEP 563 die from __future__ import annotations Future-Anweisung ein, die alle Annotationen in Zeichenketten umwandelt.

Diese Anweisung ist jedoch jetzt veraltet und wird voraussichtlich in einer zukünftigen Version von Python entfernt. Diese Entfernung wird nicht erfolgen, bevor Python 3.13 sein Lebensende im Jahr 2029 erreicht hat, was die letzte Python-Version ohne Unterstützung für die verzögerte Auswertung von Annotationen ist.

In Python 3.14 ist das Verhalten von Code, der from __future__ import annotations verwendet, unverändert.

Änderungen in der C-API

  • Py_Finalize() löscht nun alle internen Zeichenketten. Dies ist abwärtsinkompatibel zu jeder C-Erweiterung, die eine interne Zeichenkette nach einem Aufruf von Py_Finalize() festhält und dann nach einem Aufruf von Py_Initialize() wiederverwendet. Alle Probleme, die sich aus diesem Verhalten ergeben, führen normalerweise zu Abstürzen während der Ausführung des nachfolgenden Aufrufs von Py_Initialize() durch den Zugriff auf nicht initialisierten Speicher. Um dies zu beheben, verwenden Sie einen Adress-Sanitizer, um jegliche Verwendung nach der Freigabe von einer internen Zeichenkette zu identifizieren und diese während des Modul-Shutdowns freizugeben. (Beigetragen von Eddie Elizondo in gh-113601.)

  • Die Unicode-Ausnahmeobjekte C API wirft nun einen TypeError, wenn ihr Ausnahmeargument kein UnicodeError-Objekt ist. (Beigetragen von Bénédikt Tran in gh-127691.)