Zusammenfassung

Wie in PEP 236 erwähnt, gibt es keine klare Möglichkeit für „simulierte interaktive Shells“, das Verhalten von __future__-Anweisungen in „echten“ interaktiven Shells zu simulieren, d. h. die Auswirkungen von __future__-Anweisungen für die gesamte Lebensdauer der Shell beizubehalten.

Die PEP nutzt auch die Gelegenheit, das andere in PEP 236 erwähnte ungelöste Problem zu bereinigen, nämlich die Unfähigkeit, zu verhindern, dass compile() die Auswirkungen von zukünftigen Anweisungen erbt, die den Code beeinflussen, der compile() aufruft.

Diese PEP schlägt vor, das erste Problem durch Hinzufügen eines optionalen vierten Arguments zur integrierten Funktion „compile“ zu lösen, indem Informationen zu den _Feature-Instanzen hinzugefügt werden, die in __future__.py definiert sind, und durch Hinzufügen von Mechanismen zu den Standardbibliotheksmodulen „codeop“ und „code“, um die Erstellung solcher Shells zu erleichtern.

Das zweite Problem wird gelöst, indem einfach ein *weiteres* optionales Argument zu compile() hinzugefügt wird, das, wenn es ungleich Null ist, das Erben von Auswirkungen zukünftiger Anweisungen unterdrückt.

Spezifikation

Ich schlage vor, der integrierten Funktion „compile“ ein viertes, optionales „flags“-Argument hinzuzufügen. Wenn dieses Argument weggelassen wird, gibt es keine Verhaltensänderung gegenüber Python 2.1.

Wenn es vorhanden ist, wird erwartet, dass es eine Ganzzahl ist, die verschiedene mögliche Kompilierungsoptionen als Bitfeld darstellt. Die Bitfelder haben die gleichen Werte wie die CO_*-Flags, die bereits vom C-Teil des Python-Interpreters verwendet werden, um sich auf zukünftige Anweisungen zu beziehen.

compile() löst eine ValueError-Ausnahme aus, wenn es keine der gesetzten Bits in den bereitgestellten Flags erkennt.

Die bereitgestellten Flags werden mit den Flags, die ohnehin gesetzt würden, bitweise verknüpft, es sei denn, das neue fünfte optionale Argument ist eine Ganzzahl ungleich Null, in welchem Fall die bereitgestellten Flags genau der verwendete Satz sind.

Die oben genannten Flags sind derzeit für Python nicht zugänglich. Ich schlage vor, .compiler_flag-Attribute zu den _Feature-Objekten in __future__.py hinzuzufügen, die die notwendigen Bits enthalten, so dass man Code schreiben könnte wie

import __future__
def compile_generator(func_def):
    return compile(func_def, "<input>", "suite",
                __future__.generators.compiler_flag)

Eine kürzliche Änderung bedeutet, dass dieselben Bits verwendet werden können, um zu prüfen, ob ein Code-Objekt mit einem bestimmten Feature kompiliert wurde; zum Beispiel

codeob.co_flags & __future__.generators.compiler_flag``

ist genau dann ungleich Null, wenn das Code-Objekt „codeob“ in einer Umgebung kompiliert wurde, in der Generatoren erlaubt waren.

Ich werde auch ein .all_feature_flags-Attribut zum Modul __future__ hinzufügen, das eine einfache Möglichkeit bietet, alle vom laufenden Interpreter unterstützten __future__-Optionen aufzulisten.

Ich schlage außerdem vor, dem Standardbibliotheksmodul codeop ein Paar Klassen hinzuzufügen.

Eine - Compile - wird eine __call__-Methode haben, die sich weitgehend wie die integrierte „compile“-Funktion von 2.1 verhält, mit dem Unterschied, dass sie nach der Kompilierung einer __future__-Anweisung diese „merkt“ und allen nachfolgenden Code mit der aktivierten __future__-Option kompiliert.

Dies wird durch die Verwendung der neuen Features des oben erwähnten __future__-Moduls erfolgen.

Objekte der anderen Klasse, die zu codeop hinzugefügt wird - CommandCompiler - werden die Aufgabe der bestehenden Funktion codeop.compile_command übernehmen, jedoch in einer __future__-fähigen Weise.

Schließlich schlage ich vor, die Klasse InteractiveInterpreter im Standardbibliotheksmodul code zu modifizieren, um einen CommandCompiler zu verwenden, um das Verhalten der Standard-Python-Shell noch genauer nachzuahmen.

Abwärtskompatibilität

Sollte sehr wenige oder keine geben; die Änderungen an compile werden keine Auswirkungen auf vorhandenen Code haben, und das Hinzufügen neuer Funktionen oder Klassen zu codeop wird ebenfalls keine Auswirkungen haben. Vorhandener Code, der code.InteractiveInterpreter verwendet, kann sein Verhalten ändern, aber nur zum Besseren, da die „echte“ Python-Shell besser nachgeahmt wird.

Vorwärtskompatibilität

Das Basteln, das in Lib/__future__.py vorgenommen werden muss, wenn ein __future__-Feature hinzugefügt wird, wird etwas komplizierter sein. Alles andere sollte einfach funktionieren.

Probleme

Ich hoffe, die obige Schnittstelle ist für Jython nicht zu störend zu implementieren.

Implementierung

Eine Reihe von vorläufigen Implementierungen finden Sie unter [1].

Nach leichter Bearbeitung durch Tim Peters wurden sie nun eingecheckt.

Referenzen

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.