ImportEngine API

Die vorgeschlagene Erweiterung besteht aus den folgenden Objekten

importlib.engine.ImportEngine

from_engine(self, other)

Erstellt ein neues Importobjekt aus einer anderen `ImportEngine`-Instanz. Das neue Objekt wird mit einer Kopie des Status in other initialisiert. Wenn es auf `importlib engine.sysengine` aufgerufen wird, kann `from_engine()` verwendet werden, um ein `ImportEngine`-Objekt mit einer **Kopie** des globalen Importstatus zu erstellen.

__import__(self, name, globals={}, locals={}, fromlist=[], level=0)

Neurealisierung der integrierten Funktion `__import__()`. Der Import eines Moduls erfolgt unter Verwendung des Status, der in der `ImportEngine`-Instanz gespeichert ist, anstatt des globalen Importstatus. Für eine vollständige Dokumentation der `__import__`-Funktionalität siehe [2]. `__import__()` aus `ImportEngine` und seinen Unterklassen kann verwendet werden, um das Verhalten der `import`-Anweisung anzupassen, indem `__builtin__.__import__` durch `ImportEngine().__import__` ersetzt wird.

import_module(name, package=None)

Eine Neurealisierung von `importlib.import_module()`, die den in der `ImportEngine`-Instanz gespeicherten Importstatus verwendet. Siehe [3] für eine vollständige Referenz.

modules, path, path_hooks, meta_path, path_importer_cache

Instanzspezifische Versionen ihrer prozessglobalen sys-Äquivalente

importlib.engine.GlobalImportEngine(ImportEngine)

Bequemlichkeitsklasse, um einen Engine-ähnlichen Zugriff auf den globalen Status zu ermöglichen. Bietet `__import__()`, `import_module()` und `from_engine()`-Methoden wie `ImportEngine`, schreibt aber durch zum globalen Status in sys.

Zur Unterstützung verschiedener Namespace-Paketmechanismen sollten beim Ändern von sys.path Tools wie `pkgutil.extend_path` verwendet werden, um auch andere Teile des Importstatus zu ändern (in diesem Fall Paket `__path__`-Attribute). Der Pfad-Importer-Cache sollte auch bei einer Vielzahl von Änderungen ungültig gemacht werden.

Die `ImportEngine`-API bietet praktische Methoden, die verwandte Importstatusaktualisierungen automatisch als Teil einer einzigen Operation durchführen.

Globale Variablen

importlib.engine.sysengine

Eine vordefinierte Instanz von `GlobalImportEngine`. Gedacht für die Verwendung durch Importer und Loader, die aktualisiert wurden, um optionale `engine`-Parameter zu akzeptieren, und mit `ImportEngine.from_engine(sysengine)`, um mit einer Kopie des prozessglobalen Importstatus zu beginnen.

Keine Änderungen an den Finder/Loader-Schnittstellen

Anstatt zu versuchen, die PEP 302-APIs zur Unterstützung zusätzlicher Status zu aktualisieren, schlägt diese PEP vor, dass `ImportEngine` das Content-Management-Protokoll unterstützt (ähnlich den Kontext-Substitutionsmechanismen im Modul `decimal`).

Der Kontextverwaltungsmechanismus für `ImportEngine` würde

• Beim Eintritt: * Den Import-Sperrmechanismus erwerben * Den globalen Importstatus durch den eigenen Status der Import-Engine ersetzen
• Beim Austritt: * Den vorherigen globalen Importstatus wiederherstellen * Den Import-Sperrmechanismus freigeben

Die genaue API hierfür ist noch zu definieren (wird aber wahrscheinlich ein separates Kontextverwaltungsobjekt verwenden, ähnlich dem, das von `decimal.localcontext` erstellt wird).

API-Design für den Rückfall auf den globalen Importstatus

Der aktuelle Vorschlag beruht auf der `from_engine()`-API, um auf den globalen Importstatus zurückzufallen. Es kann wünschenswert sein, eine Variante anzubieten, die stattdessen dynamisch auf den globalen Importstatus zurückfällt.

Ein großer Vorteil des Beginns mit einem möglichst isolierten Design ist jedoch, dass es möglich wird, mit Unterklassen zu experimentieren, die die Grenzen zwischen dem Instanzstatus der Engine und dem prozessglobalen Status auf verschiedene Weise verwischen.

Builtin- und Erweiterungsmodule müssen prozessglobal sein

Aufgrund von Plattformbeschränkungen kann in jedem Prozess nur eine Kopie jedes integrierten und erweiterten Moduls leicht vorhanden sein. Daher ist es für jede `ImportEngine`-Instanz unmöglich, solche Module unabhängig zu laden.

Die einfachste Lösung besteht darin, dass `ImportEngine` sich weigert, solche Module zu laden, und `ImportError` auslöst. `GlobalImportEngine` könnte sie normal laden.

`ImportEngine` gibt solche Module immer noch aus einem vorab gefüllten Modul-Cache zurück – nur das direkte Laden verursacht Probleme.

Geltungsbereich der Ersetzung

Im Zusammenhang mit der vorherigen offenen Frage steht die Frage, welcher Status beim Verwenden der Kontextmanagement-API ersetzt werden soll. Es ist derzeit der Fall, dass das Ersetzen von `sys.modules` aufgrund von zwischengespeicherten Referenzen unzuverlässig sein kann, und es gibt die zugrundeliegende Tatsache, dass unabhängige Kopien einiger Module aufgrund von Plattformbeschränkungen einfach unmöglich sind.

Als Teil dieser PEP muss explizit dokumentiert werden

• Welche Teile des globalen Importstatus ersetzt werden können (und Code deklarieren, der Referenzen auf diesen Status speichert, ohne den Fall der Ersetzung fehlerhaft zu behandeln)
• Welche Teile in-place geändert werden müssen (und daher nicht durch die `ImportEngine`-Kontextmanagement-API ersetzt werden, oder anderweitig auf `ImportEngine`-Instanzen beschränkt sind)