Prozessglobaler Zustand

C-seitige statische Variablen. Da dies eine sehr Low-Level-Speicherung ist, muss sie sorgfältig verwaltet werden.

Pro Modulzustand

Zustand, der auf ein Modulobjekt beschränkt ist und dynamisch als Teil der Initialisierung eines Modulobjekts alloziert wird. Dies isoliert den Zustand von anderen Instanzen des Moduls (einschließlich denen in anderen Subinterpretern).

Zugänglich über PyModule_GetState().

Statischer Typ

Ein Typobjekt, das als C-seitige statische Variable definiert ist, d. h. ein fest einkompiliertes Typobjekt.

Ein statischer Typ muss zwischen Modulinstanzen geteilt werden und hat keine Informationen darüber, zu welchem Modul er gehört. Statische Typen haben kein `__dict__` (obwohl ihre Instanzen dies haben könnten).

Heap-Typ

Ein Typobjekt, das zur Laufzeit erstellt wird.

Definierende Klasse

Die definierende Klasse einer Methode (entweder gebunden oder ungebunden) ist die Klasse, auf der die Methode definiert wurde. Eine Klasse, die die Methode lediglich von ihrer Basis erbt, ist nicht die definierende Klasse.

Zum Beispiel ist int die definierende Klasse von True.to_bytes, True.__floor__ und int.__repr__.

In C ist die definierende Klasse diejenige, die mit dem entsprechenden Eintrag in `tp_methods` oder "tp slots" [1] definiert wurde. Für in Python definierte Methoden wird die definierende Klasse in der `__class__` Closure-Zelle gespeichert.

C-API

Die "Python/C API", wie in der Python-Dokumentation beschrieben. CPython implementiert die C-API, aber andere Implementierungen existieren.

Slot-Methoden

Die oben genannten Änderungen decken keine Slot-Methoden wie `tp_iter` oder `nb_add` ab.

Das Problem bei Slot-Methoden ist, dass ihre C-API fest ist, sodass wir nicht einfach ein neues Argument hinzufügen können, um die definierende Klasse zu übergeben. Zwei mögliche Lösungen wurden für dieses Problem vorgeschlagen:

• Suchen Sie die Klasse, indem Sie den MRO durchlaufen. Dies ist potenziell teuer, wird aber verwendbar sein, wenn die Leistung keine Rolle spielt (z. B. beim Auslösen einer Ausnahme auf Modulebene).
• Speichern eines Zeigers auf die definierende Klasse jedes Slots in einer separaten Tabelle, `__typeslots__` [2]. Dies ist technisch machbar und schnell, aber ziemlich invasiv.

Module, die von diesem Problem betroffen sind, haben auch die Möglichkeit, Thread-lokalen Zustand oder PEP 567 Kontextvariablen als Caching-Mechanismus zu verwenden oder ein eigenes Cache-Schema zur Neuladung zu definieren.

Die allgemeine Lösung des Problems wird auf einen zukünftigen PEP verschoben.

Hinzufügen von Modulreferenzen zu Heap-Typen

Eine neue Factory-Methode wird der C-API zum Erstellen von Modulen hinzugefügt

PyObject* PyType_FromModuleAndSpec(PyObject *module,
                                   PyType_Spec *spec,
                                   PyObject *bases)

Diese verhält sich wie PyType_FromSpecWithBases und ordnet zusätzlich das bereitgestellte Modulobjekt dem neuen Typ zu. (In CPython setzt dies `ht_module` wie unten beschrieben.)

Zusätzlich wird ein Akzessor, PyObject * PyType_GetModule(PyTypeObject *), bereitgestellt. Er gibt das mit dem Typ verbundene Modul zurück, falls vorhanden, andernfalls wird TypeError gesetzt und NULL zurückgegeben. Wenn ein statischer Typ übergeben wird, wird immer TypeError gesetzt und NULL zurückgegeben.

Zur Implementierung in CPython erhält die Struktur `PyHeapTypeObject` ein neues Mitglied, `PyObject *ht_module`, das einen Zeiger auf das zugehörige Modul speichert. Es wird standardmäßig auf `NULL` gesetzt und sollte nach der Erstellung des Typobjekts nicht mehr geändert werden.

Das Mitglied `ht_module` wird nicht an Unterklassen vererbt; es muss für jeden einzelnen Typ, der es benötigt, mit `PyType_FromSpecWithBases` gesetzt werden.

Normalerweise führt die Erstellung einer Klasse mit gesetztem `ht_module` zu einem Referenzzyklus, der die Klasse und das Modul umfasst. Dies ist kein Problem, da das Herunterfahren von Modulen kein leistungskritischer Vorgang ist und Modulfunktionen typischerweise ebenfalls Referenzzyklen erzeugen. Der bestehende Code zum "Setzen aller Modulglobalen auf None", der Funktionszyklen über `f_globals` durchbricht, wird auch die neuen Zyklen über `ht_module` durchbrechen.

Übergabe der definierenden Klasse an Erweiterungsmethoden

Ein neues Signaturflag, `METH_METHOD`, wird für die Verwendung in `PyMethodDef.ml_flags` hinzugefügt. Konzeptionell fügt es `defining_class` zur Funktionssignatur hinzu. Um die anfängliche Implementierung zu erleichtern, kann das Flag nur als `(METH_FASTCALL | METH_KEYWORDS | METH_METHOD)` verwendet werden. (Es kann nicht mit anderen Flags wie `METH_O` oder einfachem `METH_FASTCALL` verwendet werden, kann aber mit `METH_CLASS` oder `METH_STATIC` kombiniert werden).

C-Funktionen für Methoden, die mit dieser Flag-Kombination definiert wurden, werden über eine neue C-Signatur namens `PyCMethod` aufgerufen.

PyObject *PyCMethod(PyObject *self,
                    PyTypeObject *defining_class,
                    PyObject *const *args,
                    size_t nargsf,
                    PyObject *kwnames)

Weitere Kombinationen wie `(METH_VARARGS | METH_METHOD)` können zukünftig hinzugefügt werden (oder bereits in der anfänglichen Implementierung dieses PEP). `METH_METHOD` sollte jedoch immer ein *zusätzliches* Flag sein, d. h. die definierende Klasse sollte nur übergeben werden, wenn sie benötigt wird.

In CPython wird eine neue Struktur, die `PyCFunctionObject` erweitert, hinzugefügt, um die zusätzlichen Informationen zu speichern.

typedef struct {
    PyCFunctionObject func;
    PyTypeObject *mm_class; /* Passed as 'defining_class' arg to the C func */
} PyCMethodObject;

Die `PyCFunction`-Implementierung übergibt `mm_class` an eine `PyCMethod`-C-Funktion, wenn sie feststellt, dass das `METH_METHOD`-Flag gesetzt ist. Ein neues Makro `PyCFunction_GET_CLASS(cls)` wird für einen einfacheren Zugriff auf `mm_class` hinzugefügt.

C-Methoden können weiterhin die anderen `METH_*`-Signaturen verwenden, wenn sie keinen Zugriff auf ihre definierende Klasse/ihr Modul benötigen. Wenn `METH_METHOD` nicht gesetzt ist, ist das Umwandeln in `PyCMethodObject` ungültig.

Argument Clinic

Um die Übergabe der definierenden Klasse an Methoden, die Argument Clinic verwenden, zu unterstützen, wird ein neuer Konverter namens `defining_class` zum Argument Clinic-Tool von CPython hinzugefügt.

Jede Methode kann nur ein Argument mit diesem Konverter verwenden, und es muss nach `self` oder, falls `self` nicht verwendet wird, als erstes Argument erscheinen. Das Argument hat den Typ `PyTypeObject *`.

Bei Verwendung wählt Argument Clinic `METH_FASTCALL | METH_KEYWORDS | METH_METHOD` als Aufrufkonvention. Das Argument wird nicht in `__text_signature__` erscheinen.

Der neue Konverter wird anfänglich nicht mit `__init__` und `__new__`-Methoden kompatibel sein, die die `METH_METHOD`-Konvention nicht verwenden können.

Helfer

Der Zugriff auf den pro Modulzustand von einem Heap-Typ aus ist eine sehr häufige Aufgabe. Um dies zu erleichtern, wird ein Helfer hinzugefügt.

void *PyType_GetModuleState(PyObject *type)

Diese Funktion nimmt einen Heap-Typ entgegen und gibt im Erfolgsfall einen Zeiger auf den Zustand des Moduls zurück, zu dem der Heap-Typ gehört.

Bei einem Fehler können zwei Szenarien eintreten. Wenn ein Nicht-Typ-Objekt oder ein Typ ohne Modul übergeben wird, wird `TypeError` gesetzt und `NULL` zurückgegeben. Wenn das Modul gefunden wird, wird der Zeiger auf den Zustand, der `NULL` sein kann, zurückgegeben, ohne eine Ausnahme zu setzen.

Module, die in der anfänglichen Implementierung konvertiert wurden

Zur Validierung des Ansatzes wird das Modul `_elementtree` während der anfänglichen Implementierung modifiziert.

Slot-Methoden

Eine Möglichkeit zur Übergabe der definierenden Klasse (oder des Modulzustands) an Slot-Methoden kann zukünftig hinzugefügt werden.

Eine frühere Version dieses PEP schlug eine Hilfsfunktion vor, die eine definierende Klasse durch Suchen des MRO nach einer Klasse, die einen Slot für eine bestimmte Funktion definiert, ermittelt. Dieser Ansatz würde jedoch fehlschlagen, wenn eine Klasse mutiert wird (was für Heap-Typen von Python-Code aus möglich ist). Die Lösung dieses Problems wird zukünftigen Diskussionen überlassen.

Einfache Erstellung von Typen mit Modulreferenzen

Es wäre möglich, einen Ausführungsslot-Typ nach PEP 489 hinzuzufügen, um die Erstellung von Heap-Typen erheblich einfacher zu machen als den Aufruf von `PyType_FromModuleAndSpec`. Dies wird einem zukünftigen PEP überlassen.

Es könnte gut sein, eine gute Möglichkeit hinzuzufügen, statische Ausnahmetypen aus der begrenzten API zu erstellen. Solche Ausnahmetypen könnten zwischen Subinterpretern geteilt werden, aber ohne spezifischen Modulzustand instanziiert werden. Dies wird ebenfalls zukünftigen Diskussionen überlassen.

Optimierung

Wie hier vorgeschlagen, unterstützen Methoden, die mit dem `METH_METHOD`-Flag definiert wurden, nur eine spezifische Signatur.

Wenn sich herausstellt, dass aus Leistungsgründen andere Signaturen benötigt werden, können diese hinzugefügt werden.