Zusammenfassung

Dieses PEP schlägt eine Neugestaltung der Art und Weise vor, wie integrierte und Erweiterungsmodule mit der Import-Maschinerie interagieren. Dies wurde zuletzt für Python 3.0 in PEP 3121 überarbeitet, löste aber damals nicht alle Probleme. Ziel ist es, importbezogene Probleme zu lösen, indem Erweiterungsmodule näher an das Verhalten von Python-Modulen gebracht werden; insbesondere soll in den Modul-Spec-basierten Ladevorgang eingehakt werden, der in PEP 451 eingeführt wurde.

Dieser Vorschlag ist inspiriert von PyType_Spec aus PEP 384, um Erweiterungsautoren zu ermöglichen, nur die benötigten Funktionen zu definieren und zukünftige Ergänzungen zu Erweiterungsmoduldeklarationen zu ermöglichen.

Erweiterungsmodule werden in einem zweistufigen Prozess erstellt, der besser in die Modul-Spec-Architektur passt und Parallelen zu __new__ und __init__ von Klassen aufweist.

Erweiterungsmodule können sicher beliebige C-Level-Modulzustände im Modul speichern, die von der normalen Garbage Collection abgedeckt werden und das Neuladen sowie Sub-Interpreter unterstützen. Erweiterungsautoren werden ermutigt, diese Aspekte bei der Verwendung der neuen API zu berücksichtigen.

Der Vorschlag erlaubt auch Erweiterungsmodule mit nicht-ASCII-Namen.

Nicht alle Probleme, die in PEP 3121 angegangen wurden, sind in diesem Vorschlag gelöst. Insbesondere Probleme mit der Laufzeit-Modulsuche (PyState_FindModule) werden einem zukünftigen PEP überlassen.

Motivation

Python-Module und Erweiterungsmodule werden nicht auf dieselbe Weise eingerichtet. Bei Python-Modulen wird zuerst das Modulobjekt erstellt und eingerichtet, dann wird der Modulcode ausgeführt (PEP 302). Ein Modul-Spec-Objekt (PEP 451) wird verwendet, um Informationen über das Modul zu speichern und an die relevanten Hooks übergeben.

Bei Erweiterungen (d. h. dynamischen Bibliotheken) und integrierten Modulen wird die Modul-Init-Funktion sofort ausgeführt und übernimmt sowohl die Erstellung als auch die Initialisierung. Die Initialisierungsfunktion erhält nicht die Modul-Spec oder Informationen daraus, wie z. B. __file__ oder den voll qualifizierten Namen. Dies behindert relative Imports und das Laden von Ressourcen.

In Py3 werden Module auch nicht zu sys.modules hinzugefügt, was bedeutet, dass ein (möglicherweise transitiver) Neuimport des Moduls es tatsächlich versucht und somit in eine Endlosschleife gerät, wenn es die Modul-Init-Funktion erneut ausführt. Ohne Zugriff auf den voll qualifizierten Modulnamen ist es auch nicht trivial, das Modul korrekt zu sys.modules hinzuzufügen. Dies ist insbesondere ein Problem für Cython-generierte Module, bei denen es nicht unüblich ist, dass der Modul-Init-Code die gleiche Komplexität aufweist wie bei jedem "regulären" Python-Modul. Auch der Mangel an Informationen über __file__ und __name__ behindert die Kompilierung von " __init__.py"-Modulen, d. h. Paketen, insbesondere bei Verwendung relativer Imports zur Modul-Initialisierungszeit.

Darüber hinaus haben die meisten aktuell bestehenden Erweiterungsmodule Probleme mit der Unterstützung von Sub-Interpretern und/oder Interpreter-Neuladen, und obwohl dies mit der aktuellen Infrastruktur möglich ist, ist es weder einfach noch effizient. Die Behebung dieser Probleme war das Ziel von PEP 3121, aber viele Erweiterungen, einschließlich einiger in der Standardbibliothek, wählten den Ansatz des geringsten Aufwands für die Portierung auf Python 3 und ließen diese Probleme ungelöst. Dieses PEP behält die Rückwärtskompatibilität bei, was den Druck verringern und Erweiterungsautoren ausreichend Zeit geben sollte, diese Probleme bei der Portierung zu berücksichtigen.

Der aktuelle Prozess

Derzeit exportieren Erweiterungs- und integrierte Module eine Initialisierungsfunktion namens "PyInit_modulename", benannt nach dem Dateinamen der dynamischen Bibliothek. Diese Funktion wird von der Import-Maschinerie ausgeführt und muss ein vollständig initialisiertes Modulobjekt zurückgeben. Die Funktion erhält keine Argumente, so dass sie nichts über ihren Importkontext weiß.

Während ihrer Ausführung erstellt die Modul-Init-Funktion ein Modulobjekt basierend auf einem PyModuleDef-Objekt. Dann initialisiert sie es weiter, indem sie Attribute zum Modul-Dictionary hinzufügt, Typen erstellt usw.

Im Hintergrund behält der Lader der dynamischen Bibliothek eine Notiz über den voll qualifizierten Modulnamen des zuletzt geladenen Moduls, und wenn ein Modul mit übereinstimmendem Namen erstellt wird, wird diese globale Variable verwendet, um den voll qualifizierten Namen des Modulobjekts zu bestimmen. Dies ist nicht ganz sicher, da es davon abhängt, dass die Modul-Init-Funktion zuerst ihr eigenes Modulobjekt erstellt, aber diese Annahme hält in der Praxis normalerweise stand.

Der Vorschlag

Die Initialisierungsfunktion (PyInit_modulename) darf einen Zeiger auf ein PyModuleDef-Objekt zurückgeben. Die Import-Maschinerie ist dafür verantwortlich, das Modulobjekt zu erstellen und Hooks, die in der PyModuleDef angegeben sind, in den relevanten Phasen der Initialisierung (wie unten beschrieben) aufzurufen.

Diese Multi-Phasen-Initialisierung ist eine zusätzliche Möglichkeit. Die Einzelphasen-Initialisierung, die aktuelle Praxis, ein vollständig initialisiertes Modulobjekt zurückzugeben, wird weiterhin akzeptiert, so dass bestehender Code unverändert funktioniert, einschließlich binärer Kompatibilität.

Die Struktur PyModuleDef wird geändert, um eine Liste von Slots zu enthalten, ähnlich wie PyType_Spec aus PEP 384 für Typen. Um die binäre Kompatibilität zu erhalten und die Einführung einer neuen Struktur zu vermeiden (was zusätzliche unterstützende Funktionen und pro Modul Speicherplatz einführen würde), wird der derzeit ungenutzte m_reload-Zeiger von PyModuleDef geändert, um die Slots zu halten. Die Strukturen sind definiert als

typedef struct {
    int slot;
    void *value;
} PyModuleDef_Slot;

typedef struct PyModuleDef {
    PyModuleDef_Base m_base;
    const char* m_name;
    const char* m_doc;
    Py_ssize_t m_size;
    PyMethodDef *m_methods;
    PyModuleDef_Slot *m_slots;  /* changed from `inquiry m_reload;` */
    traverseproc m_traverse;
    inquiry m_clear;
    freefunc m_free;
} PyModuleDef;

Das m_slots-Mitglied muss entweder NULL sein oder auf ein Array von PyModuleDef_Slot-Strukturen zeigen, die durch einen Slot mit der ID 0 abgeschlossen werden (d. h. {0, NULL}).

Um einen Slot anzugeben, muss eine eindeutige Slot-ID bereitgestellt werden. Neue Python-Versionen können neue Slot-IDs einführen, aber Slot-IDs werden niemals wiederverwendet. Slots können veraltet sein, aber werden während der gesamten Python 3.x-Version unterstützt.

Der Wertzeiger eines Slots darf nicht NULL sein, es sei denn, dies wird in der Dokumentation des Slots anderweitig angegeben.

Die folgenden Slots sind derzeit verfügbar und werden später beschrieben

• Py_mod_create
• Py_mod_exec

Unbekannte Slot-IDs führen dazu, dass der Import mit SystemError fehlschlägt.

Bei Verwendung der Multi-Phasen-Initialisierung wird das m_name-Feld von PyModuleDef während des Imports nicht verwendet; der Modulname wird aus der Modul-Spec übernommen.

Bevor das PyModuleDef-Objekt von PyInit zurückgegeben wird, muss es mit der neu hinzugefügten Funktion PyModuleDef_Init initialisiert werden. Dies setzt den Objekttyp (der bei bestimmten Compilern nicht statisch gesetzt werden kann), die Referenzanzahl und interne Buchhaltungsdaten (m_index). Zum Beispiel würde ein Erweiterungsmodul "example" exportiert als

static PyModuleDef example_def = {...}

PyMODINIT_FUNC
PyInit_example(void)
{
    return PyModuleDef_Init(&example_def);
}

Das PyModuleDef-Objekt muss für die gesamte Lebensdauer des daraus erstellten Moduls verfügbar sein – üblicherweise wird es statisch deklariert.

class BuiltinImporter:
    def create_module(self, spec):
        module = _imp.create_builtin(spec)

    def exec_module(self, module):
        _imp.exec_dynamic(module)

    def load_module(self, name):
        # use a backwards compatibility shim
        _load_module_shim(self, name)

class ExtensionFileLoader:
    def create_module(self, spec):
        module = _imp.create_dynamic(spec)

    def exec_module(self, module):
        _imp.exec_dynamic(module)

    def load_module(self, name):
        # use a backwards compatibility shim
        _load_module_shim(self, name)

def create_dynamic(spec):
    name = spec.name
    path = spec.origin

    # Find an already loaded module that used single-phase init.
    # For multi-phase initialization, mod is NULL, so a new module
    # is always created.
    mod = _PyImport_FindExtensionObject(name, name)
    if mod:
        return mod

    return _PyImport_LoadDynamicModuleWithSpec(spec)

def exec_dynamic(module):
    if not isinstance(module, types.ModuleType):
        # non-modules are skipped -- PyModule_GetDef fails on them
        return

    def = PyModule_GetDef(module)
    state = PyModule_GetState(module)
    if state is NULL:
        PyModule_ExecDef(module, def)

def create_builtin(spec):
    name = spec.name

    # Find an already loaded module that used single-phase init.
    # For multi-phase initialization, mod is NULL, so a new module
    # is always created.
    mod = _PyImport_FindExtensionObject(name, name)
    if mod:
        return mod

    for initname, initfunc in PyImport_Inittab:
        if name == initname:
            m = initfunc()
            if isinstance(m, PyModuleDef):
                def = m
                return PyModule_FromDefAndSpec(def, spec)
            else:
                # fall back to single-phase initialization
                module = m
                _PyImport_FixupExtensionObject(module, name, name)
                return module

def _PyImport_LoadDynamicModuleWithSpec(spec):
    path = spec.origin
    package, dot, name = spec.name.rpartition('.')

    # see the "Non-ASCII module names" section for export_hook_name
    hook_name = export_hook_name(name)

    # call platform-specific function for loading exported function
    # from shared library
    exportfunc = _find_shared_funcptr(hook_name, path)

    m = exportfunc()
    if isinstance(m, PyModuleDef):
        def = m
        return PyModule_FromDefAndSpec(def, spec)

    module = m

    # fall back to single-phase initialization
    ....

def PyModule_FromDefAndSpec(def, spec):
    name = spec.name
    create = None
    for slot, value in def.m_slots:
        if slot == Py_mod_create:
            create = value
    if create:
        m = create(spec, def)
    else:
        m = PyModule_New(name)

    if isinstance(m, types.ModuleType):
        m.md_state = None
        m.md_def = def

    if def.m_methods:
        PyModule_AddFunctions(m, def.m_methods)
    if def.m_doc:
        PyModule_SetDocString(m, def.m_doc)

def PyModule_ExecDef(module, def):
    if isinstance(module, types.module_type):
        if module.md_state is NULL:
            # allocate a block of zeroed-out memory
            module.md_state = _alloc(module.md_size)

    if def.m_slots is NULL:
        return

    for slot, value in def.m_slots:
        if slot == Py_mod_exec:
            value(module)

PyObject* (*PyModuleCreateFunction)(PyObject *spec, PyModuleDef *def)

int (*PyModuleExecFunction)(PyObject* module)

#include <Python.h>

static int spam_exec(PyObject *module) {
    PyModule_AddStringConstant(module, "food", "spam");
    return 0;
}

#ifdef Py_mod_exec
static PyModuleDef_Slot spam_slots[] = {
    {Py_mod_exec, spam_exec},
    {0, NULL}
};
#endif

static PyModuleDef spam_def = {
    PyModuleDef_HEAD_INIT,                      /* m_base */
    "spam",                                     /* m_name */
    PyDoc_STR("Utilities for cooking spam"),    /* m_doc */
    0,                                          /* m_size */
    NULL,                                       /* m_methods */
#ifdef Py_mod_exec
    spam_slots,                                 /* m_slots */
#else
    NULL,
#endif
    NULL,                                       /* m_traverse */
    NULL,                                       /* m_clear */
    NULL,                                       /* m_free */
};

PyMODINIT_FUNC
PyInit_spam(void) {
#ifdef Py_mod_exec
    return PyModuleDef_Init(&spam_def);
#else
    PyObject *module;
    module = PyModule_Create(&spam_def);
    if (module == NULL) return NULL;
    if (spam_exec(module) != 0) {
        Py_DECREF(module);
        return NULL;
    }
    return module;
#endif
}

PyObject * PyModule_FromDefAndSpec(PyModuleDef *def, PyObject *spec)
PyObject * PyModule_FromDefAndSpec2(PyModuleDef *def, PyObject *spec,
                                    int module_api_version)

PyAPI_FUNC(int) PyModule_ExecDef(PyObject *module, PyModuleDef *def)

PyObject * PyModuleDef_Init(PyModuleDef *);

int PyModule_SetDocString(PyObject *, const char *)
int PyModule_AddFunctions(PyObject *, PyMethodDef *)

def export_hook_name(name):
    try:
        suffix = b'_' + name.encode('ascii')
    except UnicodeEncodeError:
        suffix = b'U_' + name.encode('punycode').replace(b'-', b'_')
    return b'PyInit' + suffix

import importlib.machinery
import importlib.util
loader = importlib.machinery.ExtensionFileLoader(name, path)
spec = importlib.util.spec_from_loader(name, loader)
module = importlib.util.module_from_spec(spec)
loader.exec_module(module)
return module

Zusammenfassung der API-Änderungen und Ergänzungen

Neue Funktionen

• PyModule_FromDefAndSpec (Makro)
• PyModule_FromDefAndSpec2
• PyModule_ExecDef
• PyModule_SetDocString
• PyModule_AddFunctions
• PyModuleDef_Init

Neue Makros

• Py_mod_create
• Py_mod_exec

Neue Typen

• PyModuleDef_Type wird freigegeben

Neue Strukturen

• PyModuleDef_Slot

Weitere Änderungen

PyModuleDef.m_reload wird zu PyModuleDef.m_slots geändert.

BuiltinImporter und ExtensionFileLoader implementieren nun create_module und exec_module.

Das interne Modul _imp wird abwärtsinkompatible Änderungen erfahren: create_builtin, create_dynamic und exec_dynamic werden hinzugefügt; init_builtin, load_dynamic werden entfernt.

Die undokumentierten Funktionen imp.load_dynamic und imp.init_builtin werden durch abwärtskompatible Shim-Funktionen ersetzt.

Mögliche zukünftige Erweiterungen

Der Slot-Mechanismus, inspiriert von PyType_Slot aus PEP 384, ermöglicht spätere Erweiterungen.

Einige Erweiterungsmodule exportieren viele Konstanten; z. B. hat _ssl eine lange Liste von Aufrufen im Format

PyModule_AddIntConstant(m, "SSL_ERROR_ZERO_RETURN",
                        PY_SSL_ERROR_ZERO_RETURN);

Die Konvertierung dies in eine deklarative Liste, ähnlich wie bei PyMethodDef, würde Boilerplate reduzieren und kostenlose Fehlerüberprüfung bieten, die oft fehlt.

Zeichenkettenkonstanten und Typen können ähnlich behandelt werden. (Beachten Sie, dass Nicht-Standard-Basen für Typen nicht portabel statisch angegeben werden können; dieser Fall würde eine Py_mod_exec-Funktion erfordern, die läuft, bevor die Slots hinzugefügt werden. Die kostenlose Fehlerüberprüfung wäre jedoch immer noch von Vorteil.)

Eine weitere Möglichkeit ist die Bereitstellung einer " main"-Funktion, die ausgeführt wird, wenn das Modul mit dem -m-Schalter von Python übergeben wird. Damit dies funktioniert, muss das Modul runpy modifiziert werden, um die in PEP 451 eingeführte Modul-Spec-basierte Ladung zu nutzen. Außerdem muss ein Mechanismus zum Einrichten eines Moduls gemäß Slots, mit denen es ursprünglich nicht definiert wurde, hinzugefügt werden.

Implementierung

Eine WIP-Implementierung ist in einem GitHub-Repository [3] verfügbar; ein Patchset befindet sich unter [4].

Vorherige Ansätze

Stefan Behnel's initiales Proto-PEP [1] hatte einen "PyInit_modulename"-Hook, der eine Modulklasse erstellen würde, deren __init__ dann aufgerufen würde, um das Modul zu erstellen. Dieser Vorschlag entsprach nicht dem (damals nicht existenten) PEP 451, bei dem die Modulerstellung und -initialisierung in separate Schritte unterteilt ist. Er unterstützte auch nicht das Laden einer Erweiterung in bereits vorhandene Modulobjekte.

Alyssa (Nick) Coghlan schlug die "Create"- und "Exec"-Hooks vor und schrieb eine Prototypimplementierung [2]. Zu dieser Zeit war PEP 451 noch nicht implementiert, daher verwendete der Prototyp kein ModuleSpec.

Die ursprüngliche Version dieses PEP verwendete "Create"- und "Exec"-Hooks und erlaubte das Laden in beliebige vorkonstruierte Objekte mit dem "Exec"-Hook. Der Vorschlag brachte die Initialisierung von Erweiterungsmodulen näher an die Art und Weise, wie Python-Module initialisiert werden, aber später wurde erkannt, dass dies kein wichtiges Ziel ist. Der aktuelle PEP beschreibt eine einfachere Lösung.

Eine weitere Iteration verwendete einen "PyModuleExport"-Hook als Alternative zu PyInit, wobei PyInit für das bestehende Schema und PyModuleExport für Multi-Phase verwendet wurde. Da der Hook-Name jedoch nicht anhand des Modulnamens bestimmt werden konnte, erschwerte dies die automatische Generierung von PyImport_Inittab durch Tools wie freeze. Das Beibehalten nur des PyInit-Hook-Namens, auch wenn er nicht ganz für den Export einer Definition geeignet ist, ergab eine wesentlich einfachere Lösung.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.