In CPython, der Referenzimplementierung von Python, weicht das Verhalten von locals() je nach Ausführungskontext aufgrund von Optimierungsstrategien ab. Auf Modulebene gibt locals() das globale Namespace-Dictionary selbst zurück, das die autoritative Speicherung für Variablen darstellt, sodass alle Änderungen sofort in der Umgebung reflektiert werden. Innerhalb einer Funktion hingegen verwendet CPython eine Optimierung namens "schnelle lokale Variablen", bei der Variablen in einem festgrößigen C-Array von PyObject*-Zeigern gespeichert werden, die nach Bytecode indiziert sind, anstatt in einer Hashtabelle. Wenn locals() innerhalb einer Funktion aufgerufen wird, erstellt CPython ein neues Dictionary und füllt es, indem es Werte aus diesem schnellen lokalen Array kopiert, was einen temporären Schnappschuss ergibt. Folglich aktualisieren Schreiben an dieses Dictionary nur die ephemeral Zuordnung, ohne das zugrunde liegende schnelle lokale Array zu verändern, sodass die Funktion weiterhin die ursprünglichen Variablenwerte verwendet.
Ein Entwicklungsteam baute ein dynamisches Debugging-Tool, das es Entwicklern ermöglichte, temporäre Hilfsvariablen in den laufenden Funktionsbereich über eine Remote-Debugger-Schnittstelle einzufügen. Die erste Implementierung erfasste locals() an einem Haltepunkt, injizierte Hilfsobjekte in das zurückgegebene Dictionary und erwartete, dass die laufende Funktion auf diese Hilfsmittel in den folgenden Zeilen zugreifen konnte.
Der erste Ansatz versuchte, das durch locals() zurückgegebene Dictionary direkt zu ändern, in der Annahme, dass es sich um eine lebende Referenz auf den Funktionsnamespace handele. Vorteile: Es erforderte keine Änderungen an den Funktionssignaturen und schien syntaktisch einfach. Nachteile: Es schlug stillschweigend fehl, weil CPython dieses Dictionary als schreibgeschützten Schnappschuss des schnellen lokalen Arrays behandelt; Änderungen wurden verworfen, wodurch die tatsächlichen lokalen Variablen unverändert blieben.
Die zweite Strategie beinhaltete die Injektion des temporären Zustands in globals() stattdessen, wobei der globale Namespace als gemeinsames schwarzes Brett verwendet wurde. Vorteile: Diese Methode hielt Daten im gesamten Anwendungsbereich und war überall zugänglich, ohne Argumente übergeben zu müssen. Nachteile: Es führte zu erheblichen Thread-Sicherheitsrisiken, verschmutzte den globalen Namespace mit transienten Debugging-Daten und verletzte Kapselungsprinzipien, indem es den internen Zustand dem gesamten Prozess aussetzte.
Die endgültige Lösung bestand darin, die instrumentierten Funktionen so umzugestalten, dass sie ein explizites context-Dictionary-Argument akzeptierten, über das der Debugger veränderbaren Zustand übergeben konnte. Vorteile: Dieser Ansatz ist explizit, thread-sicher und funktioniert identisch in CPython, PyPy und Jython und hält sich an das Python-Prinzip, dass explizit besser ist als implizit. Nachteile: Es erforderte die Modifizierung der Funktionssignaturen und Aufrufstellen, was mehr anfängliche Umstrukturierung als die anderen Ansätze beinhaltete.
Das Team nahm die explizite context-Pass-Strategie an. Dies beseitigte die Abhängigkeit von CPython-spezifischen Implementierungsdetails, verhinderte Namespace-Verschmutzung und führte zu einem stabilen, plattformübergreifenden Debugging-Utility.
Warum verhält sich locals() innerhalb einer Listenkomprehension anders als in einer normalen Schleife auf Modulebene?
In Python 3 führen Listenkomprehensionen ihren eigenen lokalen Geltungsbereich ein, ähnlich wie bei einer geschachtelten Funktion, um eine Variablenleckage von der Schleifenvariable in den umgebenden Namespace zu verhindern. Wenn locals() innerhalb einer Komprehension aufgerufen wird, gibt es das Dictionary für diesen temporären Geltungsbereich zurück und nicht die umschließende Funktion oder das Modul. Darüber hinaus ist dieses Dictionary, ähnlich wie in regulären Funktionen, ein Schnappschuss von schnellen lokalen Variablen, wenn die Komprehension als separates Code-Objekt implementiert ist, sodass Schreibvorgänge daran nicht bestehen bleiben. Im Gegensatz dazu ist locals() auf Modulebene ein Alias für globals(), das das lebende Modul-Dictionary ist. Diese Unterscheidung ist entscheidend, da Entwickler oft annehmen, dass Komprehensionen denselben lokalen Namespace wie ihren umgebenden Block teilen, was zu Verwirrung führt, wenn sie versuchen, Variablen darin zu debuggen oder einzufügen.
Kann man einen Schreibvorgang auf schnelle lokale Variablen erzwingen, indem man das Frame-Objekt über sys._getframe() manipuliert, und welche Risiken sind dabei verbunden?
Fortgeschrittene Benutzer können den aktuellen Ausführungsrahmen mithilfe von sys._getframe() abrufen und frame.f_locals ändern, was CPython als schreibbare Zuordnung bereitstellt. In einigen Versionen kann das Zuweisen zu frame.f_locals einen Schreibvorgang auf das schnelle lokale Array über interne APIs wie PyFrame_LocalsToFast auslösen, aber dieses Verhalten ist implementationsabhängig, versionenanfällig und kein Teil der Sprachspezifikation. Die Risiken umfassen Speicherbeschädigung, wenn die Referenzzählungen nicht korrekt verwaltet werden, inkonsistentes Verhalten, bei dem der Optimierer die aktualisierten Werte ignoriert, weil es sie bereits in Registern oder im Array zwischengespeichert hat, und vollständiges Scheitern in anderen Python-Implementierungen wie PyPy, die überhaupt keine Architektur für schnelle lokale Arrays verwenden. Sich auf diese Technik zu verlassen, führt zu undefiniertem Verhalten und macht den Code in verschiedenen Python-Versionen unmöglich zu pflegen.
Wie wirkt sich das Vorhandensein von exec() oder eval() mit expliziten lokalen Variablen auf die Optimierung der schnellen lokalen Variablen in einer Funktion aus?
Wenn ein Funktionskörper einen exec()- oder eval()-Aufruf enthält, der auf den lokalen Namespace verweist, kann CPython nicht garantieren, dass Variablen nur über das optimierte schnelle lokale Array zugegriffen werden; der ausgeführte String könnte dynamisch Variablen einführen oder löschen. Um dem Rechnung zu tragen, deaktiviert der Compiler die schnelle lokale Optimierung für diese Funktion und fällt zurück auf die Speicherung aller lokalen Variablen in einem Standard-Dictionary, das für jeden Zugriff konsultiert wird. In diesem "nicht optimierten" Modus gibt locals() dieses tatsächliche Dictionary zurück, wodurch es zu einer lebendigen, veränderlichen Ansicht wird, in der Änderungen sofort bestehen bleiben. Dies erklärt, warum Code, der exec() verwendet, oft langsamer läuft und warum locals() in solchen Funktionen "korrekt" (Schreibvorgänge erlaubend) zu funktionieren scheint, während es in optimierten Funktionen nicht der Fall ist.