Der Funktionzeiger-Typ

Aufrufe erfolgen über einen Funktionzeiger, der die folgenden Parameter entgegennimmt

• PyObject *callable: Das aufgerufene Objekt
• PyObject *const *args: Ein Vektor von Argumenten
• size_t nargs: Die Anzahl der Argumente plus das optionale Flag PY_VECTORCALL_ARGUMENTS_OFFSET (siehe unten)
• PyObject *kwnames: Entweder NULL oder ein Tupel mit den Namen der Schlüsselwortargumente

Dies wird durch den Funktionzeiger-Typ implementiert: typedef PyObject *(*vectorcallfunc)(PyObject *callable, PyObject *const *args, size_t nargs, PyObject *kwnames);

Änderungen an der PyTypeObject Struktur

Der ungenutzte Slot printfunc tp_print wird durch tp_vectorcall_offset ersetzt. Er hat den Typ Py_ssize_t. Ein neues tp_flags Flag wird hinzugefügt, _Py_TPFLAGS_HAVE_VECTORCALL, das für jede Klasse gesetzt sein muss, die das Vectorcall-Protokoll verwendet.

Wenn _Py_TPFLAGS_HAVE_VECTORCALL gesetzt ist, muss tp_vectorcall_offset eine positive ganze Zahl sein. Es ist der Offset in das Objekt des Vektorcall-Funktionzeigers vom Typ vectorcallfunc. Dieser Zeiger kann NULL sein, in diesem Fall ist das Verhalten dasselbe, als ob _Py_TPFLAGS_HAVE_VECTORCALL nicht gesetzt wäre.

Der tp_print Slot wird als tp_vectorcall_offset Slot wiederverwendet, um es externen Projekten zu erleichtern, das Vectorcall-Protokoll auf frühere Python-Versionen zurückzuporten. Insbesondere hat das Cython-Projekt Interesse daran gezeigt (siehe https://mail.python.org/pipermail/python-dev/2018-June/153927.html).

Deskriptor-Verhalten

Ein zusätzliches Typ-Flag wird spezifiziert: Py_TPFLAGS_METHOD_DESCRIPTOR.

Py_TPFLAGS_METHOD_DESCRIPTOR sollte gesetzt werden, wenn das aufrufbare Objekt das Deskriptor-Protokoll verwendet, um ein gebundenes Methoden-ähnliches Objekt zu erstellen. Dies wird vom Interpreter verwendet, um die Erstellung temporärer Objekte beim Aufruf von Methoden zu vermeiden (siehe _PyObject_GetMethod und die Opcodes LOAD_METHOD/CALL_METHOD).

Konkret, wenn Py_TPFLAGS_METHOD_DESCRIPTOR für type(func) gesetzt ist, dann

• func.__get__(obj, cls)(*args, **kwds) (mit obj nicht None) muss äquivalent zu func(obj, *args, **kwds) sein.
• func.__get__(None, cls)(*args, **kwds) muss äquivalent zu func(*args, **kwds) sein.

Es gibt keine Einschränkungen für das Objekt func.__get__(obj, cls). Letzteres ist nicht verpflichtet, das Vectorcall-Protokoll zu implementieren.

Der Aufruf

Der Aufruf hat die Form ((vectorcallfunc)(((char *)o)+offset))(o, args, n, kwnames), wobei offset Py_TYPE(o)->tp_vectorcall_offset ist. Der Aufrufer ist dafür verantwortlich, das kwnames Tupel zu erstellen und sicherzustellen, dass keine Duplikate darin vorhanden sind.

n ist die Anzahl der positionsabhängigen Argumente plus möglicherweise das Flag PY_VECTORCALL_ARGUMENTS_OFFSET.

PY_VECTORCALL_ARGUMENTS_OFFSET

Das Flag PY_VECTORCALL_ARGUMENTS_OFFSET sollte zu n hinzugefügt werden, wenn der Aufgerufene erlaubt ist, args[-1] temporär zu ändern. Mit anderen Worten, dies kann verwendet werden, wenn args auf das Argument 1 im zugewiesenen Vektor zeigt. Der Aufgerufene muss den Wert von args[-1] vor der Rückgabe wiederherstellen.

Immer wenn sie es günstig tun können (ohne Allokation), werden Aufrufer ermutigt, PY_VECTORCALL_ARGUMENTS_OFFSET zu verwenden. Dies ermöglicht es aufrufbaren Objekten wie gebundenen Methoden, ihre nachfolgenden Aufrufe kostengünstig durchzuführen. Der Bytecode-Interpreter weist bereits Platz auf dem Stack für das aufrufbare Objekt zu, sodass er diesen Trick ohne zusätzliche Kosten nutzen kann.

Siehe [3] für ein Beispiel, wie PY_VECTORCALL_ARGUMENTS_OFFSET von einem Aufgerufenen verwendet wird, um Allokationen zu vermeiden.

Für die Ermittlung der tatsächlichen Anzahl von Argumenten aus dem Parameter n muss das Makro PyVectorcall_NARGS(n) verwendet werden. Dies ermöglicht zukünftige Änderungen oder Erweiterungen.

Unterklasse

Erweiterungstypen erben das Typ-Flag _Py_TPFLAGS_HAVE_VECTORCALL und den Wert tp_vectorcall_offset von der Basisklasse, vorausgesetzt, sie implementieren tp_call auf die gleiche Weise wie die Basisklasse. Zusätzlich wird das Flag Py_TPFLAGS_METHOD_DESCRIPTOR geerbt, wenn tp_descr_get auf die gleiche Weise wie die Basisklasse implementiert wird.

Heap-Typen erben nie das Vectorcall-Protokoll, da dies nicht sicher wäre (Heap-Typen können dynamisch geändert werden). Diese Einschränkung kann in Zukunft aufgehoben werden, erfordert aber eine Sonderbehandlung von __call__ in type.__setattribute__.

Änderungen an bestehenden Klassen

Die Klassen function, builtin_function_or_method, method_descriptor, method, wrapper_descriptor, method-wrapper werden das Vectorcall-Protokoll verwenden (nicht alle werden in der anfänglichen Implementierung geändert).

Für builtin_function_or_method und method_descriptor (die die PyMethodDef Datenstruktur verwenden), könnte man einen spezifischen Vectorcall-Wrapper für jede bestehende Aufrufkonvention implementieren. Ob sich das lohnt, bleibt abzuwarten.

Verwendung des Vectorcall-Protokolls für Klassen

Für eine Klasse cls erfordert die Erstellung einer neuen Instanz mit cls(xxx) mehrere Aufrufe. Mindestens ein Zwischenobjekt wird für jeden Aufruf in der Sequenz type.__call__, cls.__new__, cls.__init__ erstellt. Es ist daher sehr sinnvoll, Vectorcall für den Aufruf von Klassen zu verwenden. Dies bedeutet tatsächlich die Implementierung des Vectorcall-Protokolls für type. Einige der am häufigsten verwendeten Klassen werden dieses Protokoll verwenden, wahrscheinlich range, list, str und type.

Das PyMethodDef Protokoll und Argument Clinic

Argument Clinic [4] generiert automatisch Wrapper-Funktionen um Low-Level-Callables, die eine sichere Entpackung von primitiven Typen und andere Sicherheitsprüfungen ermöglichen. Argument Clinic könnte erweitert werden, um Wrapper-Objekte zu generieren, die dem neuen vectorcall Protokoll entsprechen. Dies ermöglicht es der Ausführung, vom Aufrufer zum von Argument Clinic generierten Wrapper und dann zum handgeschriebenen Code mit nur einer einzigen Indirektion zu fließen.

bpo-29259

PEP 590 ähnelt dem in bpo-29259 [1] vorgeschlagenen. Der Hauptunterschied besteht darin, dass diese PEP den Funktionzeiger in der Instanz statt in der Klasse speichert. Dies ist sinnvoller für die Implementierung von Funktionen in C, wo jede Instanz einer anderen C-Funktion entspricht. Es ermöglicht auch die Optimierung von type.__call__, was mit bpo-29259 nicht möglich ist.

PEP 576 und PEP 580

Sowohl PEP 576 als auch PEP 580 zielen darauf ab, 3rd-Party-Objekte sowohl ausdrucksstark als auch performant (auf Augenhöhe mit CPython-Objekten) zu machen. Der Zweck dieser PEP ist es, eine einheitliche Methode für den Aufruf von Objekten im CPython-Ökosystem bereitzustellen, die sowohl ausdrucksstark als auch so performant wie möglich ist.

Diese PEP hat einen breiteren Anwendungsbereich als PEP 576 und verwendet variable statt feste Offset-Funktionzeiger. Die zugrunde liegende Aufrufkonvention ist ähnlich. Da PEP 576 nur einen festen Offset für den Funktionzeiger zulässt, wären die Verbesserungen für Objekte mit Einschränkungen in ihrem Layout nicht möglich.

PEP 580 schlägt eine größere Änderung des PyMethodDef Protokolls vor, das zur Definition von Builtin-Funktionen verwendet wird. Diese PEP bietet einen allgemeineren und einfacheren Mechanismus in Form einer neuen Aufrufkonvention. Diese PEP erweitert auch das PyMethodDef Protokoll, aber nur, um bestehende Konventionen zu formalisieren.

Andere abgelehnte Ansätze

Eine längere Form mit 6 Argumenten, die sowohl Vektor- als auch optionale Tupel- und Dictionary-Argumente kombiniert, wurde in Betracht gezogen. Es wurde jedoch festgestellt, dass der Code zur Konvertierung zwischen ihr und der alten tp_call Form übermäßig umständlich und ineffizient war. Da auf x64 Windows nur 4 Argumente in Registern übergeben werden, hätten die zwei zusätzlichen Argumente nicht unerhebliche Kosten verursacht.

Das Entfernen aller Sonderfälle und die Verwendung der tp_call Form für alle Aufrufe wurde ebenfalls in Betracht gezogen. Wenn jedoch keine wesentlich effizientere Methode zur Erstellung und Zerstörung von Tupeln und, in geringerem Maße, von Dictionaries gefunden worden wäre, wäre dies zu langsam gewesen.