Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 269 – Pgen Modul für Python

Autor:
Jonathan Riehl <jriehl at spaceship.com>
Status:
Verschoben
Typ:
Standards Track
Erstellt:
24-Aug-2001
Python-Version:
2.2
Post-History:

Inhaltsverzeichnis

Zusammenfassung

Ähnlich wie das parser Modul den Python-Parser bereitstellt, schlägt diese PEP vor, dass der Parsergenerator, der zum Erstellen des Python-Parsers verwendet wird, pgen, als Modul in Python zur Verfügung gestellt wird.

Begründung

Im Laufe der Python-Geschichte gab es zahlreiche Diskussionen über die Erstellung eines Python-Kompilierers [1]. Diese führten zu mehreren Implementierungen von Python-Parsern, insbesondere dem parser Modul, das derzeit in der Standardbibliothek von Python enthalten ist [2], und Jeremy Hyltons compiler Modul [3]. Während jedoch mehrere Sprachänderungen vorgeschlagen wurden [4] [5], mangelte es der Experimentierfreudigkeit mit der Python-Syntax an einem Python-Interface für den tatsächlichen Parsergenerator, der zum Aufbau von Python verwendet wird.

Durch die Bereitstellung eines Python-Wrappers, analog zu Fred Drake Jr.s Parser-Wrapper, der jedoch auf die pgen Bibliothek abzielt, werden die folgenden Behauptungen aufgestellt:

  1. Referenzimplementierungen von Syntaxänderungen werden einfacher zu entwickeln sein. Derzeit würde eine Referenzimplementierung einer Syntaxänderung erfordern, dass der Entwickler das pgen Werkzeug von der Kommandozeile aus verwendet. Die daraus resultierende Parser-Datenstruktur müsste dann entweder zur Schnittstellenanpassung mit einer benutzerdefinierten CPython-Implementierung überarbeitet oder als C-Erweiterungsmodul gekapselt werden.
  2. Referenzimplementierungen von Syntaxänderungen werden einfacher zu verteilen sein. Da der Parsergenerator in Python verfügbar sein wird, sollte daraus folgen, dass der daraus resultierende Parser aus Python zugänglich ist. Daher sollten Referenzimplementierungen als reiner Python-Code verfügbar sein, anstatt benutzerdefinierte Versionen der bestehenden CPython-Distribution zu verwenden oder als kompilierbare Erweiterungsmodule.
  3. Referenzimplementierungen von Syntaxänderungen werden einfacher mit einem größeren Publikum zu diskutieren sein. Dies ergibt sich teilweise aus der zweiten Behauptung, da die Community der Python-Benutzer wahrscheinlich größer ist als die Community der CPython-Entwickler.
  4. Die Entwicklung kleiner Sprachen in Python wird weiter verbessert, da das zusätzliche Modul ein voll funktionsfähiger LL(1)-Parsergenerator sein wird.

Spezifikation

Das vorgeschlagene Modul wird pgen heißen. Das pgen Modul wird die folgenden Funktionen enthalten:

parseGrammarFile (fileName) -> AST

Die Funktion parseGrammarFile() liest die von fileName angezeigte Datei und erstellt ein AST-Objekt. Die AST-Knoten enthalten die nicht-terminalen, numerischen Werte der Metagrammatik des Parsergenerators. Das Ausgabe-AST ist eine Instanz der AST-Erweiterungsklasse, wie sie vom parser Modul bereitgestellt wird. Syntaxfehler in der Eingabedatei führen zum Auslösen der SyntaxError-Ausnahme.

parseGrammarString (text) -> AST

Die Funktion parseGrammarString() folgt den Semantiken der Funktion parseGrammarFile(), akzeptiert jedoch den Grammatiktext als String für die Eingabe, im Gegensatz zum Dateinamen.

buildParser (grammarAst) -> DFA

Die Funktion buildParser() akzeptiert ein AST-Objekt als Eingabe und gibt eine DFA (deterministische endliche Automaten)-Datenstruktur zurück. Die DFA-Datenstruktur ist eine C-Erweiterungsklasse, ähnlich wie die AST-Struktur im parser Modul bereitgestellt wird. Wenn das Eingabe-AST nicht mit den für die pgen Metagrammatik definierten Nicht-Terminal-Codes übereinstimmt, wirft buildParser() eine ValueError Ausnahme.

parseFile (fileName, dfa, start) -> AST

Die Funktion parseFile() ist im Wesentlichen ein Wrapper für die C-API-Funktion PyParser_ParseFile(). Der Wrapper-Code akzeptiert die DFA C-Erweiterungsklasse und den Dateinamen. Als Ausgabe wird eine AST-Instanz geliefert, die mit den lexikalischen Werten im token Modul und den in der DFA enthaltenen nicht-terminalen Werten übereinstimmt.

parseString (text, dfa, start) -> AST

Die Funktion parseString() arbeitet ähnlich wie die Funktion parseFile(), akzeptiert jedoch den zu parsenden Text als Argument. Ähnlich wie parseFile() die C-API-Funktion PyParser_ParseFile() umschließt, wird parseString() die Funktion PyParser_ParseString() umschließen.

symbolToStringMap (dfa) -> dict

Die Funktion symbolToStringMap() akzeptiert eine DFA-Instanz und gibt ein Dictionary-Objekt zurück, das die numerischen Werte der Nicht-Terminale der DFA auf die String-Namen der Nicht-Terminale abbildet, wie sie in der ursprünglichen Grammatikspezifikation für die DFA zu finden sind.

stringToSymbolMap (dfa) -> dict

Die Funktion stringToSymbolMap() gibt ein Dictionary aus, das die Namen der Nicht-Terminale der Eingabe-DFA auf ihre entsprechenden numerischen Werte abbildet.

Zusätzliche Punkte gibt es, wenn die Karten-Generierungsfunktionen und die Parsing-Funktionen auch Methoden der DFA-Erweiterungsklasse sind.

Implementierungsplan

Ein raffinierter Plan wurde ausgearbeitet, um diese Verbesserung zu realisieren:

  1. Benennen Sie die pgen Funktionen so um, dass sie den Namenskonventionen von CPython entsprechen. Diese Aktion kann die Hinzufügung einiger Header-Dateien zum Verzeichnis Include beinhalten.
  2. Verschieben Sie die pgen C-Module im Makefile.pre.in von einzigartigen pgen Elementen zur Python C-Bibliothek.
  3. Nehmen Sie alle notwendigen Änderungen am parser Modul vor, damit die AST-Erweiterungsklasse versteht, dass es AST-Typen gibt, die sie möglicherweise nicht versteht. Eine flüchtige Untersuchung der AST-Erweiterungsklasse zeigt, dass sie verfolgt, ob der Baum eine Suite oder ein Ausdruck ist.
  1. Implementieren Sie ein zusätzliches C-Modul im Verzeichnis Modules. Das C-Erweiterungsmodul implementiert die DFA-Erweiterungsklasse und die in der vorherigen Sektion beschriebenen Funktionen.
  2. Fügen Sie das neue Modul zum Build-Prozess hinzu. Tatsächlich Hexerei.

Einschränkungen

Unter diesem Vorschlag wären die Designer von Python 3000 immer noch an die lexikalischen Konventionen von Python gebunden. Die Addition, Subtraktion oder Modifikation des Python-Lexers liegt außerhalb des Umfangs dieser PEP.

Referenzimplementierung

Derzeit wird keine Referenzimplementierung bereitgestellt. Ein Patch wurde irgendwann unter http://sourceforge.net/tracker/index.php?func=detail&aid=599331&group_id=5470&atid=305470 bereitgestellt, aber dieser Patch wird nicht mehr gepflegt.

Referenzen

Quelle: https://github.com/python/peps/blob/main/peps/pep-0269.rst

Zuletzt geändert: 2025-02-01 08:55:40 GMT