Beispiel

Nehmen wir an, wir haben ein Modul spam.py

# simulate some work
import time
time.sleep(10)
print("spam loaded")

Und ein Modul eggs.py, das es importiert

import spam
print("imports done")

Wenn wir python -L eggs.py ausführen, wird das Modul spam niemals importiert (da es nach dem Import nie referenziert wird), "spam loaded" wird niemals gedruckt, und es gibt keine 10-sekündige Verzögerung.

Aber wenn eggs.py den Namen spam nach dem Import einfach referenziert, reicht das aus, um den Import von spam.py auszulösen

import spam
print("imports done")
spam

Wenn wir nun python -L eggs.py ausführen, sehen wir zuerst die Ausgabe "imports done", dann eine 10-sekündige Verzögerung und dann "spam loaded", nachdem dies ausgegeben wurde.

Natürlich ist es in realen Anwendungsfällen (insbesondere bei Lazy Imports) nicht ratsam, sich auf Import-Nebeneffekte wie diese zu verlassen, um echte Arbeit auszulösen. Dieses Beispiel dient nur zur Klärung des Verhaltens von Lazy Imports.

Eine andere Möglichkeit, den Effekt von Lazy Imports zu erklären, ist, als ob jede Lazy-Import-Anweisung stattdessen direkt vor jeder Verwendung des importierten Namens im Quellcode geschrieben worden wäre. Man kann sich Lazy Imports also ähnlich wie die Transformation dieses Codes vorstellen

import foo

def func1():
    return foo.bar()

def func2():
    return foo.baz()

Zu diesem

def func1():
    import foo
    return foo.bar()

def func2():
    import foo
    return foo.baz()

Dies gibt einen guten Eindruck davon, wann der Import von foo bei Lazy Imports stattfindet, aber Lazy Import ist nicht wirklich äquivalent zu dieser Code-Transformation. Es gibt mehrere bemerkenswerte Unterschiede

• Im Gegensatz zum letzteren Code existiert unter Lazy Imports der Name foo immer noch im globalen Namespace des Moduls und kann von anderen Modulen, die dieses importieren, importiert oder referenziert werden. (Solche Referenzen würden ebenfalls den Import auslösen.)
• Der Laufzeit-Overhead von Lazy Imports ist deutlich geringer als im letzteren Fall; nach der ersten Referenz auf den Namen foo, die den Import auslöst, haben nachfolgende Referenzen null Import-System-Overhead; sie sind von einer normalen Namensreferenz nicht zu unterscheiden.

In gewissem Sinne verwandeln Lazy Imports die Importanweisung in eine reine Deklaration eines importierten Namens oder mehrerer Namen, die später bei Referenzierung vollständig aufgelöst werden.

Ein Import im Stil from foo import bar kann ebenfalls lazy sein. Wenn der Import stattfindet, wird der Name bar als Lazy Import in den Modul-Namespace aufgenommen. Die erste Referenz auf bar importiert foo und löst bar zu foo.bar auf.

Gedachte Verwendung

Da Lazy Imports eine potenziell rückwärts inkompatible semantische Änderung darstellen, sollten sie nur vom Autor oder Maintainer einer Python-Anwendung aktiviert werden, der bereit ist, die Anwendung gründlich unter den neuen Semantiken zu testen, sicherzustellen, dass sie wie erwartet funktioniert, und bei Bedarf bestimmte Imports auszuoptieren (siehe unten). Lazy Imports sollten nicht spekulativ vom Endbenutzer einer Python-Anwendung mit der Erwartung eines Erfolgs aktiviert werden.

Es liegt in der Verantwortung des Anwendungsentwicklers, der Lazy Imports für seine Anwendung aktiviert, alle Bibliotheksimports auszuoptieren, die für das korrekte Funktionieren seiner Anwendung als eager erforderlich sind; es liegt nicht in der Verantwortung der Bibliotheksautoren, sicherzustellen, dass ihre Bibliothek sich unter Lazy Imports exakt gleich verhält.

Die Dokumentation der Funktion, der -L Flagge und der neuen importlib APIs wird klar über die beabsichtigte Verwendung und die Risiken der Einführung ohne Tests informieren.

Implementierung

Lazy Imports werden intern durch ein „lazy import“-Objekt dargestellt. Wenn ein Lazy Import stattfindet (z. B. import foo oder from foo import bar), wird der Schlüssel "foo" oder "bar" sofort zum Namespace-Dictionary des Moduls hinzugefügt, aber mit seinem Wert auf ein nur intern verwendetes „lazy import“-Objekt gesetzt, das alle notwendigen Metadaten zur späteren Ausführung des Imports speichert.

Ein neues boolesches Flag in PyDictKeysObject (dk_lazy_imports) wird gesetzt, um anzuzeigen, dass dieses spezielle Dictionary Lazy Import-Objekte enthalten kann. Dieses Flag wird nur verwendet, um alle Lazy-Objekte bei „Bulk“-Operationen effizient aufzulösen, wenn ein Dictionary Lazy-Objekte enthalten kann.

Immer wenn ein Schlüssel in einem Dictionary nachgeschlagen wird, um seinen Wert zu extrahieren, wird der Wert daraufhin überprüft, ob es sich um ein Lazy Import-Objekt handelt. Wenn ja, wird das Lazy-Objekt sofort aufgelöst, die relevanten importierten Module ausgeführt, das Lazy Import-Objekt im Dictionary (wenn möglich) durch den tatsächlichen importierten Wert ersetzt und der aufgelöste Wert von der Lookup-Funktion zurückgegeben. Ein Dictionary könnte als Teil eines Import-Nebeneffekts während der Auflösung eines Lazy Import-Objekts mutieren. In diesem Fall ist es nicht möglich, den Schlüsselwert effizient durch das aufgelöste Objekt zu ersetzen. In diesem Fall erhält das Lazy Import-Objekt einen gecachten Verweis auf das aufgelöste Objekt. Bei der nächsten Verwendung wird dieser gecachte Verweis zurückgegeben und das Lazy Import-Objekt im Dictionary durch den aufgelösten Wert ersetzt.

Da dies alles intern von der Dictionary-Implementierung gehandhabt wird, können Lazy Import-Objekte niemals aus dem Modul-Namespace ausbrechen und für Python-Code sichtbar werden; sie werden immer bei ihrer ersten Referenz aufgelöst. Keine Stub-, Dummy- oder Thunk-Objekte sind jemals für Python-Code sichtbar oder in sys.modules platziert. Wenn ein Modul lazy importiert wird, erscheint bis zu seiner tatsächlichen Importierung beim ersten Zugriff überhaupt kein Eintrag dafür in sys.modules.

Wenn zwei verschiedene Module (moda und modb) beide einen Lazy import foo enthalten, hat das Namespace-Dictionary jedes Moduls ein unabhängiges Lazy Import-Objekt unter dem Schlüssel "foo", das den Import desselben foo-Moduls verzögert. Dies ist kein Problem. Wenn es zuerst eine Referenz auf z. B. moda.foo gibt, wird das Modul foo wie üblich importiert und in sys.modules platziert, und das Lazy-Objekt unter dem Schlüssel moda.__dict__["foo"] wird durch das tatsächliche Modul foo ersetzt. An diesem Punkt bleibt modb.__dict__["foo"] ein Lazy Import-Objekt. Wenn später auf modb.foo zugegriffen wird, wird ebenfalls versucht, foo zu importieren. Dieser Import findet das Modul bereits in sys.modules vor, wie es bei nachfolgenden Imports desselben Moduls in Python normal ist, und zu diesem Zeitpunkt wird das Lazy Import-Objekt bei modb.__dict__["foo"] durch das tatsächliche Modul foo ersetzt.

Es gibt zwei Fälle, in denen ein Lazy Import-Objekt ein Dictionary verlassen kann

• In ein anderes Dictionary: Um die Leistung von Bulk-Kopieroperationen wie dict.update() und dict.copy() aufrechtzuerhalten, prüfen diese nicht auf Lazy Import-Objekte und lösen sie nicht auf. Wenn das Quell-Dict jedoch das Flag dk_lazy_imports gesetzt hat, das anzeigt, dass es Lazy-Objekte enthalten kann, wird dieses Flag an das aktualisierte/kopierte Dictionary weitergegeben. Dies stellt immer noch sicher, dass das Lazy Import-Objekt nicht ohne Auflösung in Python-Code ausbrechen kann.
• Über den Garbage Collector: Lazy importierte Objekte sind immer noch Python-Objekte und leben im Garbage Collector; als solche können sie gesammelt und z. B. über gc.get_objects() eingesehen werden. Wenn ein Lazy-Objekt auf diese Weise für Python-Code sichtbar wird, ist es opak und inert; es hat keine nützlichen Methoden oder Attribute. Ein repr() davon würde so aussehen: <lazy_object 'fully.qualified.name'>.

Wenn ein Lazy-Objekt einem Dictionary hinzugefügt wird, wird das Flag dk_lazy_imports gesetzt. Sobald es gesetzt ist, wird das Flag nur gelöscht, wenn *alle* Lazy Import-Objekte im Dictionary aufgelöst sind, z. B. vor der Dictionary-Iteration.

Alle Dictionary-Iterationsmethoden, die Werte beinhalten (wie dict.items(), dict.values(), PyDict_Next() usw.), versuchen, *alle* Lazy Import-Objekte im Dictionary aufzulösen, bevor die Iteration beginnt. Da nur (einige) Modul-Namespace-Dictionaries dk_lazy_imports gesetzt haben werden, werden die zusätzlichen Overheads der Auflösung aller Lazy Import-Objekte innerhalb eines Dictionaries nur von denjenigen Dictionaries getragen, die sie benötigen. Die Minimierung des Overheads bei normalen, nicht-lazy Dictionaries ist der alleinige Zweck des Flags dk_lazy_imports.

PyDict_Next versucht, alle Lazy Import-Objekte beim ersten Zugriff auf Position 0 aufzulösen, und diese Imports könnten mit Ausnahmen fehlschlagen. Da PyDict_Next keine Ausnahme setzen kann, gibt PyDict_Next in diesem Fall sofort 0 zurück, und jede Ausnahme wird als nicht aufhebbare Ausnahme auf stderr ausgegeben.

Aus diesem Grund führt dieses PEP PyDict_NextWithError ein, das sich genauso verhält wie PyDict_Next, aber einen Fehler setzen kann, wenn es 0 zurückgibt, und dies sollte nach dem Aufruf über PyErr_Occurred() überprüft werden.

Die Eager-Natur von Imports innerhalb von try / except / with Blöcken oder innerhalb von Klassen- oder Funktionsdefinitionen wird im Compiler über einen neuen EAGER_IMPORT_NAME Opcode gehandhabt, der immer eager importiert. Top-Level-Imports verwenden IMPORT_NAME, was je nach -L und/oder importlib.set_lazy_imports() lazy oder eager sein kann.

Debugging

Debug-Protokollierung von python -v wird protokolliert, wann immer eine Importanweisung angetroffen wurde, aber die Ausführung des Imports aufgeschoben wird.

Pythons Funktion -X importtime zur Profilerstellung von Importkosten passt sich natürlich an Lazy Imports an; die profilierte Zeit ist die Zeit, die tatsächlich für den Import aufgewendet wird.

Obwohl Lazy Import-Objekte im Allgemeinen nicht für Python-Code sichtbar sind, kann es in einigen Debugging-Fällen nützlich sein, von Python-Code aus zu überprüfen, ob der Wert an einem bestimmten Schlüssel in einem bestimmten Dictionary ein Lazy Import-Objekt ist, ohne dessen Auflösung auszulösen. Zu diesem Zweck kann importlib.is_lazy_import() verwendet werden

from importlib import is_lazy_import

import foo

is_lazy_import(globals(), "foo")

foo

is_lazy_import(globals(), "foo")

In diesem Beispiel gibt, wenn Lazy Imports aktiviert wurden, der erste Aufruf von is_lazy_import True zurück und der zweite False.

Pro-Modul-Opt-Out

Aufgrund der unten genannten Rückwärtskompatibilitätsprobleme kann es für eine Anwendung, die Lazy Imports verwendet, notwendig sein, bestimmte Imports als eager zu erzwingen.

Im eigenen Code, da Imports innerhalb eines try- oder with-Blocks niemals lazy sind, kann dies einfach erreicht werden

try:  # force these imports to be eager
    import foo
    import bar
finally:
    pass

Dieses PEP schlägt die Hinzufügung eines neuen Kontextmanagers importlib.eager_imports() vor, damit die obige Technik weniger umständlich ist und keine Kommentare zur Verdeutlichung der Absicht benötigt.

from importlib import eager_imports

with eager_imports():
    import foo
    import bar

Da Imports innerhalb von Kontextmanagern immer eager sind, kann der eager_imports() Kontextmanager einfach ein Alias für einen Null-Kontextmanager sein. Die Wirkung des Kontextmanagers ist nicht transitiv: foo und bar werden eager importiert, aber Imports innerhalb dieser Module folgen weiterhin den üblichen Lazy-Regeln.

Der schwierigere Fall kann auftreten, wenn ein Import in Code von Drittanbietern, der nicht einfach geändert werden kann, als eager erzwungen werden muss. Zu diesem Zweck nimmt importlib.set_lazy_imports() ein zweites optionales, nur-keyword-Argument excluding entgegen, das auf einen Container von Modulnamen gesetzt werden kann, innerhalb dessen alle Imports eager sind

from importlib import set_lazy_imports

set_lazy_imports(excluding=["one.mod", "another"])

Die Auswirkung hiervon ist ebenfalls oberflächlich: Alle Imports innerhalb von one.mod sind eager, aber nicht Imports in allen Modulen, die von one.mod importiert werden.

Der Parameter excluding von set_lazy_imports() kann ein Container beliebiger Art sein, der daraufhin überprüft wird, ob er einen Modulnamen enthält. Wenn der Modulname im Objekt enthalten ist, werden Imports darin eager sein. Daher kann beliebige Opt-out-Logik in einer __contains__ Methode kodiert werden

import re
from importlib import set_lazy_imports

class Checker:
    def __contains__(self, name):
        return re.match(r"foo\.[^.]+\.logger", name)

set_lazy_imports(excluding=Checker())

Wenn Python mit der Flagge -L ausgeführt wurde, sind Lazy Imports bereits global aktiviert, und die einzige Auswirkung des Aufrufs von set_lazy_imports(True, excluding=...) ist das globale Setzen der eager Modulnamen/Callback. Wenn set_lazy_imports(True) ohne das excluding Argument aufgerufen wird, wird die Ausschlussliste/Callback gelöscht und alle geeigneten Imports (Modul-Level-Imports, die nicht in try/except/with sind und keine import * sind) sind von diesem Zeitpunkt an lazy.

Dieses Opt-out-System ist so konzipiert, dass die Möglichkeit einer lokalen Begründung über die Lazy-Natur eines Imports erhalten bleibt. Sie müssen nur den Code eines Moduls und das excluding Argument zu set_lazy_imports, falls vorhanden, sehen, um zu wissen, ob ein gegebener Import eager oder lazy sein wird.

Testen

Die CPython-Testsuite wird mit aktivierten Lazy Imports bestanden (mit einigen übersprungenen Tests). Ein Buildbot sollte die Testsuite mit aktivierten Lazy Imports ausführen.

C API

Für Autoren von C-Erweiterungsmodulen ist die vorgeschlagene öffentliche C-API wie folgt

• void PyDict_ResolveLazyImports(PyObject *dict) löst alle Lazy-Objekte in einem Dictionary auf, falls vorhanden. Muss vor dem Aufruf von PyDict_NextWithError() oder PyDict_Next() verwendet werden.
• PyDict_NextWithError() funktioniert genauso wie PyDict_Next(), mit der Ausnahme, dass alle Fehler an den Aufrufer weitergegeben werden, indem 0 zurückgegeben und eine Ausnahme gesetzt wird. Der Aufrufer sollte PyErr_Occurred() verwenden, um auf Fehler zu prüfen.

Import-Nebeneffekte

Import-Nebenwirkungen, die sonst durch die Ausführung importierter Module während der Ausführung von Import-Anweisungen erzeugt würden, werden aufgeschoben, bis auf die importierten Objekte zugegriffen wird.

Diese Import-Nebenwirkungen können umfassen

• Code, der während des Imports nebenwirkungsbehaftete Logik ausführt;
• Abhängigkeit von importierten Untermodulen, die als Attribute im übergeordneten Modul gesetzt sind.

Ein relevanter und typischer betroffener Fall ist die click-Bibliothek zum Erstellen von Python-Kommandozeilen-Schnittstellen. Wenn z.B. cli = click.group() in main.py definiert ist und sub.py cli aus main importiert und ihm über einen Dekorator Unterbefehle hinzufügt (@cli.command(...)), der eigentliche cli()-Aufruf aber in main.py steht, können verzögerte Imports verhindern, dass die Unterbefehle registriert werden, da in diesem Fall Click von Nebenwirkungen des Imports von sub.py abhängt. In diesem Fall besteht die Lösung darin, sicherzustellen, dass der Import von sub.py sofort erfolgt, z.B. durch die Verwendung des Kontextmanagers importlib.eager_imports().

Dynamische Pfade

Es könnte Probleme mit dynamischen Python-Importpfaden geben; insbesondere das Hinzufügen (und anschließende Entfernen nach dem Import) von Pfaden aus sys.path

sys.path.insert(0, "/path/to/foo/module")
import foo
del sys.path[0]
foo.Bar()

In diesem Fall, wenn verzögerte Imports aktiviert sind, erfolgt der Import von foo nicht tatsächlich, während die Ergänzung zu sys.path vorhanden ist.

Eine einfache Lösung dafür (die auch den Code-Stil verbessert und die Bereinigung sicherstellt) wäre, die sys.path-Modifikationen in einen Kontextmanager zu legen. Dies löst das Problem, da Imports innerhalb eines with-Blocks immer sofort erfolgen.

Aufgeschobene Ausnahmen

Ausnahmen, die während eines verzögerten Imports auftreten, blubbern nach oben und löschen die teilweise erstellten Module aus sys.modules, genau wie Ausnahmen während eines normalen Imports.

Da Fehler, die während eines verzögerten Imports ausgelöst werden, später auftreten als bei einem sofortigen Import (d.h. überall dort, wo auf den Namen zuerst zugegriffen wird), ist es auch möglich, dass sie versehentlich von Ausnahmehandhabern abgefangen werden, die nicht damit rechneten, dass der Import innerhalb ihres try-Blocks ausgeführt wird, was zu Verwirrung führt.

Umschließen von aufgeschobenen Ausnahmen

Um die Verwirrung zu verringern, könnten Ausnahmen, die bei der Ausführung eines verzögerten Imports auftreten, durch eine LazyImportError-Ausnahme (eine Unterklasse von ImportError) ersetzt werden, mit einem __cause__, der auf die ursprüngliche Ausnahme gesetzt ist.

Die Sicherstellung, dass alle Fehler bei verzögerten Imports als LazyImportError ausgelöst werden, würde die Wahrscheinlichkeit verringern, dass sie versehentlich abgefangen und mit einer anderen erwarteten Ausnahme verwechselt werden. In der Praxis gab es jedoch Fälle, z.B. innerhalb von Tests, wo fehlerhafte Module die Ausnahme unittest.SkipTest auslösen und dies ebenfalls in LazyImportError gewickelt würde, was dazu führt, dass solche Tests fehlschlagen, da der eigentliche Ausnahmetyp verborgen ist. Die Nachteile scheinen hier den hypothetischen Fall zu überwiegen, dass unerwartete verzögerte Ausnahmen versehentlich abgefangen werden.

Pro-Modul-Opt-In

Ein pro-Modul-Opt-in mittels zukünftiger Imports (d.h. from __future__ import lazy_imports) ist nicht sinnvoll, da __future__-Imports keine Feature-Flags sind, sondern für den Übergang zu Verhaltensweisen, die in Zukunft zum Standard werden. Es ist nicht klar, ob verzögerte Imports jemals als Standardverhalten sinnvoll sein werden, daher sollten wir dies nicht mit einem __future__-Import versprechen.

Es gibt andere Fälle, in denen eine Bibliothek lokal verzögerte Imports für ein bestimmtes Modul aktivieren möchte; z.B. ein verzögertes Top-Level- __init__.py für eine große Bibliothek, um ihre Unterkomponenten als verzögerte Attribute zugänglich zu machen. Vorerst, um die Funktion einfacher zu halten, konzentriert sich dieses PEP auf den Anwendungsfall "Anwendung" und befasst sich nicht mit dem Anwendungsfall Bibliothek. Der zugrunde liegende Mechanismus der Verzögerung, der in diesem PEP eingeführt wird, könnte in Zukunft auch zur Adressierung dieses Anwendungsfalls verwendet werden.

Explizite Syntax für einzelne Lazy-Imports

Wenn das Hauptziel von verzögerten Imports ausschließlich darin bestünde, Importzyklen und Vorwärtsreferenzen zu umgehen, wäre eine explizit gekennzeichnete Syntax für bestimmte gezielte Imports, die verzögert erfolgen sollen, sehr sinnvoll. Aber in der Praxis wäre es sehr schwierig, mit diesem Ansatz robuste Startzeit- oder Speichernutzungsvorteile zu erzielen, da dies erfordern würde, die meisten Imports in Ihrer Codebasis (und in Drittanbieterabhängigkeiten) zu konvertieren, um die Syntax für verzögerte Imports zu verwenden.

Es wäre möglich, eine "flache" Verzögerung anzustreben, bei der nur die Top-Level-Imports von Teilsystemen aus dem Hauptmodul explizit verzögert werden, während Imports innerhalb der Teilsysteme alle sofort erfolgen. Dies ist jedoch extrem fragil – es bedarf nur eines falsch platzierten Imports, um die sorgfältig konstruierte flache Verzögerung zunichte zu machen. Das globale Aktivieren von verzögerten Imports hingegen bietet eine tiefgreifende, robuste Verzögerung, bei der Sie immer nur für die genutzten Imports bezahlen.

Es mag Anwendungsfälle geben (z.B. für statisches Typisieren), bei denen einzeln markierte verzögerte Imports wünschenswert sind, um Vorwärtsreferenzen zu vermeiden, aber die Leistungs-/Speichervorteile von global verzögerten Imports nicht benötigt werden. Da dies ein anderer Satz von motivierenden Anwendungsfällen ist und eine neue Syntax erfordert, ziehen wir es vor, dies nicht in dieses PEP aufzunehmen. Ein anderes PEP könnte auf dieser Implementierung aufbauen und die zusätzliche Syntax vorschlagen.

Umgebungsvariable zur Aktivierung von Lazy-Imports

Die Bereitstellung eines Opt-in über Umgebungsvariablen begünstigt den Missbrauch der Funktion zu leicht. Es mag für einen Python-Benutzer verlockend sein, beispielsweise die Umgebungsvariable global in seiner Shell zu setzen, in der Hoffnung, alle von ihm ausgeführten Python-Programme zu beschleunigen. Diese Nutzung mit ungetesteten Programmen führt wahrscheinlich zu unbegründeten Fehlermeldungen und einer Wartungsbelastung für die Autoren dieser Tools. Um dies zu vermeiden, entscheiden wir uns dafür, überhaupt keine Umgebungsvariablen-Opt-in bereitzustellen.

Entfernen der -L Flagge

Wir stellen das -L CLI-Flag bereit, das theoretisch auf ähnliche Weise missbraucht werden könnte, indem ein Endbenutzer ein einzelnes Python-Programm ausführt, das mit python somescript.py oder python -m somescript ausgeführt wird (im Gegensatz zur Verteilung über Python-Paketierungswerkzeuge). Aber der potenzielle Missbrauchsumfang ist mit -L wesentlich geringer als mit einer Umgebungsvariable, und -L ist für einige Anwendungen wertvoll, um die Startzeitvorteile zu maximieren, indem sichergestellt wird, dass alle Imports vom Beginn eines Prozesses an verzögert werden. Daher entscheiden wir uns dafür, ihn beizubehalten.

Es ist bereits der Fall, dass die Ausführung von beliebigen Python-Programmen mit Kommandozeilen-Flags, für die sie nicht bestimmt sind (z.B. -s, -S, -E oder -I), unerwartete und fehlerhafte Ergebnisse haben kann. -L ist in dieser Hinsicht nichts Neues.

Halb-Lazy-Imports

Es wäre möglich, den Import-Loader bis zum Auffinden des Modulquellcodes eilig auszuführen, die tatsächliche Ausführung des Moduls und die Erstellung des Modulobjekts dann aber aufzuschieben. Der Vorteil wäre, dass bestimmte Klassen von Importfehlern (z.B. ein einfacher Tippfehler im Modulnamen) eilig abgefangen würden, anstatt auf die Verwendung eines importierten Namens verschoben zu werden.

Der Nachteil wäre, dass die Vorteile von verzögerten Imports bei der Startzeit erheblich reduziert würden, da ungenutzte Imports zumindest einen stat()-Aufruf auf dem Dateisystem erfordern würden. Es würde auch eine möglicherweise nicht offensichtliche Trennung zwischen *welchen* Importfehlern eilig und *welchen* verzögert ausgelöst werden, wenn verzögerte Imports aktiviert sind.

Diese Idee wird derzeit abgelehnt, da in der Praxis Verwirrung über Tippfehler bei Imports kein beobachtetes Problem bei der Referenzimplementierung war. Im Allgemeinen sind verzögerte Imports nicht für immer verzögert, und Fehler treten bald genug auf, um abgefangen und behoben zu werden (es sei denn, der Import ist wirklich ungenutzt).

Eine weitere mögliche Motivation für halb-verzögerte Imports wäre, Modulen selbst über ein Flag zu ermöglichen, ob sie verzögert oder sofort importiert werden. Dies wird sowohl abgelehnt, da es halb-verzögerte Imports erfordert und einige der Leistungsvorteile der Import-Verzögerung aufgibt, als auch weil Module im Allgemeinen nicht entscheiden, wie oder wann sie importiert werden, sondern das importierende Modul entscheidet dies. Es gibt keine klare Begründung dafür, dass dieses PEP diese Kontrolle umkehren soll; stattdessen bietet es nur mehr Optionen für den importierenden Code, die Entscheidung zu treffen.

Lazy dynamische Imports

Es wäre möglich, eine lazy=True oder eine ähnliche Option zu __import__() und/oder importlib.import_module() hinzuzufügen, um ihnen die Durchführung von verzögerten Imports zu ermöglichen. Diese Idee wird in diesem PEP aus Mangel an einem klaren Anwendungsfall abgelehnt. Dynamische Imports liegen bereits weit außerhalb der PEP 8 Code-Stil-Empfehlungen für Imports und können leicht genauso verzögert gemacht werden, wie gewünscht, indem sie an der gewünschten Stelle im Codefluss platziert werden. Diese werden nicht häufig auf Modulebene verwendet, wo verzögerte Imports angewendet werden.

Deep eager-imports-Überschreibung

Der vorgeschlagene Kontextmanager importlib.eager_imports() und die ausgeschlossenen Module in importlib.set_lazy_imports(excluding=...) überschreiben beide haben oberflächliche Effekte: sie erzwingen nur die sofortige Ausführung für den Ort, an dem sie angewendet werden, nicht transitiv. Es wäre möglich, eine tiefe/transitive Version eines oder beider bereitzustellen. Diese Idee wird in diesem PEP abgelehnt, da die Implementierung komplex wäre (unter Berücksichtigung von Threads und asynchronem Code), die Erfahrung mit der Referenzimplementierung gezeigt hat, dass sie nicht notwendig ist, und weil sie eine lokale Argumentation über die Verzögerung von Imports verhindert.

Ein tiefer Override kann zu verwirrendem Verhalten führen, da die transitiv importierten Module aus mehreren Orten importiert werden können, von denen einige den "tiefen sofortigen Override" verwenden und andere nicht. Somit können diese Module immer noch verzögert initial importiert werden, wenn sie zuerst aus einem Ort importiert werden, der den Override nicht hat.

Mit tiefen Overrides ist es nicht möglich, lokal zu argumentieren, ob ein bestimmter Import verzögert oder sofort erfolgt. Mit dem in diesem PEP spezifizierten Verhalten ist eine solche lokale Argumentation möglich.

Lazy Imports als Standardverhalten machen

Die verzögerten Imports zur Standard-/Alleinfunktion von Python-Imports zu machen, anstatt als Opt-in, hätte langfristige Vorteile, da Bibliotheksautoren (eventuell) nicht mehr die Möglichkeit beider Semantiken berücksichtigen müssten.

Die Rückwärtsinkompatibilitäten sind jedoch so, dass dies nur über einen langen Zeitraum mit einem __future__-Import in Betracht gezogen werden könnte. Es ist überhaupt nicht klar, ob verzögerte Imports zur Standard-Importsemantik für Python werden sollten.

Dieses PEP vertritt die Position, dass die Python-Community mehr Erfahrung mit verzögerten Imports sammeln muss, bevor sie in Betracht gezogen wird, sie zum Standardverhalten zu machen, daher wird dies vollständig einem möglichen zukünftigen PEP überlassen.