Zusammenfassung

Dieser PEP schlägt die Hinzufügung einer neuen integrierten Variablen namens TYPE_CHECKING vor, um die Erfahrung beim Schreiben von Python-Code mit Typanmerkungen zu verbessern. Sie wird als True ausgewertet, wenn der Code von einem statischen Typ-Checker analysiert wird, und als False während der normalen Laufzeitausführung. Im Gegensatz zu typing.TYPE_CHECKING, das diese Variable ersetzt, ist kein Import-Statement erforderlich.

Motivation

Typanmerkungen wurden für Python durch PEP 484 definiert und haben eine breite Akzeptanz gefunden. Eine Herausforderung bei vollständig annotiertem Code besteht darin, dass viele weitere Importe erforderlich sind, um den relevanten Namen in den Gültigkeitsbereich zu bringen, was ohne sorgfältiges Design zu Importzyklen führen kann. Dies wurde durch PEP 563 und später PEP 649 anerkannt, die zwei verschiedene Mechanismen für die verzögerte Auswertung von Typanmerkungen einführen. Wie in PEP 563 angemerkt, sind "Typ-Hinweise ... nicht rechenfrei". Die Konstante typing.TYPE_CHECKING wurde daher eingeführt, ursprünglich um beim Aufbrechen von zyklischen Importen zu helfen.

In Situationen, in denen die Startzeit kritisch ist, wie z. B. bei Kommandozeilenschnittstellen, Anwendungen oder Kernbibliotheken, können Programmierer alle Importanweisungen, die für die Laufzeitausführung nicht erforderlich sind, in einen „TYPE_CHECKING-Block“ setzen oder bestimmte Importe auf innerhalb von Funktionen verzögern. Das typing-Modul selbst kann jedoch bis zu 10 ms für den Import benötigen, länger als Python zur Initialisierung benötigt. Die Zeit für den Import des typing-Moduls kann eindeutig nicht ignoriert werden.

Um den Import von TYPE_CHECKING aus typing zu vermeiden, definieren Entwickler derzeit eine Modul-Variable wie TYPE_CHECKING = False oder verwenden Code wie if False:  # TYPE_CHECKING. Die Bereitstellung einer Standardmethode ermöglicht vielen Werkzeugen die konsistente Implementierung desselben Verhaltens. Sie ermöglicht es auch Drittanbieterwerkzeugen im Ökosystem, sich auf ein einziges Verhalten mit garantierten Semantiken zu einigen, da beispielsweise einige statische Typ-Checker derzeit keine lokalen Konstanten zulassen und nur typing.TYPE_CHECKING erkennen.

Spezifikation

TYPE_CHECKING ist eine integrierte Konstante und ihr Wert ist False. Im Gegensatz zu True, False, None und __debug__ ist TYPE_CHECKING keine echte Konstante; eine Zuweisung dazu löst keinen SyntaxError aus.

Statische Typ-Checker müssen TYPE_CHECKING als True behandeln, ähnlich wie typing.TYPE_CHECKING.

Wenn dieser PEP akzeptiert wird, wird die neue Konstante TYPE_CHECKING der bevorzugte Ansatz sein und der Import von typing.TYPE_CHECKING wird als veraltet markiert. Um die Laufzeitauswirkungen von Typing zu minimieren, wird diese Veralterung keine DeprecationWarning früher als am Ende der Lebensdauer von Python 3.13 generieren, die für Oktober 2029 geplant ist.

Stattdessen können Typ-Checker bei einer solchen veralteten Nutzung warnen, wenn die Zielversion des geprüften Programms als Python 3.14 oder neuer signalisiert wird.

Abwärtskompatibilität

Da TYPE_CHECKING keine Zuweisung verbietet, funktioniert vorhandener Code, der TYPE_CHECKING verwendet, weiterhin.

# This code will continue to work
TYPE_CHECKING = False
from typing import TYPE_CHECKING

Benutzer können die Zuweisung zu TYPE_CHECKING entfernen, nachdem sie Python 3.13 oder ältere Versionen nicht mehr verwenden.

Wie man das lehrt

• Verwenden Sie if TYPE_CHECKING:, um Typ-Checking-Code zur Laufzeit zu überspringen.
• Verwenden Sie from typing import TYPE_CHECKING, um Python-Versionen vor 3.14 zu unterstützen.
• Workarounds wie TYPE_CHECKING = False oder if False:  # TYPE_CHECKING funktionieren weiterhin, werden aber nicht empfohlen.

Referenzimplementierung

• python/cpython#131793

Abgelehnte Ideen

Urheberrecht

Dieses Dokument wird in die Public Domain oder unter die CC0-1.0-Universal-Lizenz gestellt, je nachdem, welche Lizenz permissiver ist.