Suche Mitstreiter für einen Python-Bytecode-Interpreter

[sma]

Ich hatte neulich begonnen, einen Python-Bytecode-Interpreter in Python zu bauen. Ursprünglich, um damit Continuations auszuprobieren, aber da es verhältnismäßig einfach war, habe ich mein Beispiel nochmals in Java gebaut und nun hätte ich Lust, das ganze zu vervollständigen und frage hiermit, ob es jemanden interessiert, mitzuhelfen. Das wäre meiner Motivation sicherlich zuträglich :)

In Python ist der Bytecode-Interpreter bestenfalls ein interessantes (und vielleicht lehrreiches) Experiment. In Java kann ich zumindest die folgenden Argumente herbeiziehen: Ich kann in Python entwickelte Software in einem Java-Umfeld (speziell bei Firmen, Stichwort: Enterprise) laufen lassen. Jython schlief so lange und ist immer noch nicht bei 2.5 angekommen, dahin komme ich mit meinem Bytecode-Interpreter vielleicht sogar schneller...

Meine Architektur ist zudem "stackless", optimiert Endrekursion und hat (bislang) keinen GIL. Damit könnte das Threading besser auf einem Mehrprozessorsystem skalieren als CPython. Außerdem hat Java den besseren Garbage Collector. Einen Geschwindigkeitsrekord werde ich dennoch nicht gewinnen: "fib" ist ca. 3x so langsam wie unter CPython.

Mein Plan wäre, ein konkretes Python-Beispiel zu wählen, das möglichst wenig Abhängigkeiten zu anderen Modulen hat und dann systematisch die fehlenden Befehle und Funktionen zu implementieren. Es gibt einige kniffelige Bereiche wie z.B. Exception-Blöcke aber häufig auch Fleißarbeit (hat man erstmal "+", sind die anderen binären Operationen nicht weiter schwer).


Stefan

[veers]

Wie hast du vor auf CPython Module zuzugreifen?

In Python ist der Bytecode-Interpreter bestenfalls ein interessantes (und vielleicht lehrreiches) Experiment.

Also ich würde PyPy als mehr als ein interessantes Experiment bezeichnen

[sma]

Wie hast du vor auf CPython Module zuzugreifen?

Das ist eines der Probleme, die noch zu lösen ist :)

In Python selbst ist es kein Problem, solange man akzeptiert, dass der Code, der beim einmaligen Laden des Moduls nicht vom Interpreter ausgeführt wird. Der Bytecode `IMPORT_NAME` lädt ein Modul und entspricht wohl der eingebauten Funktion `__import__`.

In Java wird's schwerer. Ich kann .pyc-Dateien einlesen, damit auch Module, muss aber die Suche danach selbst implementieren. Eine naive Version, die einfach im Dateisystem nach den sich aus dem Namen ergebenden .pyc-Dateien sucht, würde mir erstmal reichen. Eingebaute Module müsste man komplett nachbauen. Irgendwie zu versuchen, in C geschriebene Module einzubinden (wie es glaube ich IronPython macht) wird in Java nicht (oder nur sehr umständlich mit Hilfe von speziellen Zusatzbibliotheken) möglich sein.

Also ich würde PyPy als mehr als ein interessantes Experiment bezeichnen :)

Ich sprach von meinem Interpreter, nicht allgemein von allen denkbaren Interpretern. PyPy ist ja nicht nur ein Python-Interpreter in Python, sondern auch ein Übersetzer von (Restricted) Python in andere Sprachen (meines Wissens C, LLVM-, JVM- und CLR-Bytecode) mit dem dann der Python in Python Interpreter, geschrieben in Restricted Python, übersetzt wird in einen Python in C Interpreter, der dann mit GCC kompiliert wird.

PyPy folgt damit nach meinem Verständnis dem Ansatz von Squeak-Smalltalk, dessen VM in (einem Slang genannten Subset von) Smalltalk geschrieben ist, welches dann von einem in Smalltalk geschriebenen Smalltalk (genauer Slang) nach C Übersetzer von einem Smalltalk-VM in Slang Programm in ein Smalltalk-VM in C Programm übersetzt wird, was dann von GCC zusammen mit einem Rest an C-Code für die Interaktion mit der Außenwelt (UI, I/O, Sockets) zu einem C-Programm bzw. einen Maschinenprogramm kompiliert wird, was dann Smalltalk-Code ausführen kann.

Dahin will ich eigentlich gar nicht. Ich wäre schon zufrieden, einen Bytecode-Interpreter in Java zu haben, da ich dies erstmal für den einfachsten und am schnellsten erfolgsversprechenden Weg halte.

Ein interessantes - wenn auch fast schon zu großes - Beispiel-Python-Programm könnte web.py sein. Lässt man dort den Datenbank-Zugriff und die Templates raus, bleiben etwa 3000 Zeilen Python-Code über. Werkzeug hat eine ähnliche Größe, ist aber deutlich besser dokumentiert und strukturiert - vielleicht ist dies die bessere Wahl.

Ich hatte jetzt die Idee, das WSGI-Interface auf einem Servlet basierend nachzubauen und man könnte dann web.py-Programme in einem Java-Application-Server ablaufen lassen - ähnlich wie JRuby das für Rails-Anwendungen für Glashfish erlaubt. Wäre doch nett, einfache web.py-Anwendungen ausführen zu können. Oder gibt es ein noch kleineres Webrahmenwerk? Ich hätte gerne schnell ein Erfolgserlebnis :)

Stefan

[noise]

Hi sma, muss es den unbedingt Java sein? Sonst könnte doch Stackless Python eventuell was für dich sein? Oder geht es dir eher darum so einen Interpreter in Java zu implementieren?

[mitsuhiko]

Zum ganzen Projekt sag ich mal gar nichts, aber Werkzeug ist eine schlechte Testlib. Unser Import System hat sogar schonmal einen Python 2.4 "Bug" zu Tage gefördert.

[noise]

Zum ganzen Projekt sag ich mal gar nichts

Wenn die Frage gestatte ist: Warum hälst du nichts von dem Projekt ansich? Wäre doch nett eine JPython alternative zu haben die:
- dem aktuellen CPython entspricht
- mit tail call optimization,
- keine global interpreter lock hat und
- Continuations hat.

Das einzige Problem das ich eher sehe ist das dies ein Projekt ist, das sehr viel Zeit und eine Art Verpflichtungen zum maintainen braucht, wenn es wirklich ernsthaft für den Produktionsbetrieb geplant ist. sma, würdest du das wirklich ernsthaft maintainen wollen und dich quasi auf "Lebenszeit" verpflichten wollen oder ist das ganze eher als proof of concept gedacht?

mitsuhiko, mich würden deine Einwände und bebänken gegen das Projekt interessieren.

[sma]

Noise,

du fragtest, warum Java und nicht Stackless. Je mehr ich mich mit der Materie beschäftigt habe, desto spannender fand ich die Vorstellung, es selbst zu machen. Mir ging es auf einmal mehr um den Weg als das Ziel. Java habe ich gewählt, weil das "Enterprise-kompatibel" ist und weil im Gegensatz zu IronPython für .NET bei Jython irgendwie die Energie zu fehlen scheint. Weitere Gründe hast du selbst mitsuhiko genannt.

Dessen Ablehnung ("dazu sage ich mal nichts") kann ich nicht nachvollziehen, aber seinen Ratschlag, nicht Werkzeug als Beispiel zu nehmen, werde ich gerne annehmen. Ich schaute mir Werkzeug schon mal unter dem Aspekt des Testrahmenwerks an, und da werden alle Register gezogen, was Meta-Programmierung angeht. Aber es gibt ja genügend Webrahmenwerke für Python - eines wird schon dabei sein, dass passt :)

Was die Verpflichtung auf Lebenzeit angeht, da wirst du ganz bestimmt kein "Ja" von mir hören und das wird dir auch garantiert niemand für irgendein anderes OS-Projekt geben. Somit kann es erstmal nur ein proof of concept (PoC) sein und wenn's klappt, wird man sehen, was daraus entsteht. Ich würde mich natürlich freuen, wenn das Ergebnis auch produktiv eingesetzt werden könnte.

Mein Plan für dieses Wochenende ist jedoch erstmal ein PoC für dieses "Webapp":

Code: Alles auswählen

def app(environ, start_response):
  start_response('200 OK', [('content-type', 'text/plain')])
  return ['Hallo, Welt']

die ich dann aus einem Java-Servlet heraus aufrufen können möchte.

Stefan

[birkenfeld]

Nur mal so am Rande, wieso interpretiert ihr in "dazu sage ich mal nichts" alle Ablehnung hinein? Ich sage zu dem Projekt hier auch nichts, aber das bedeutet in dem Fall, dass ich mich schlicht nicht damit beschäftigen will.

[BlackJack]

@birkenfeld: Wer nicht für uns ist muss gegen uns sein. Du Terrorist! Äh, ups, falscher Kontext. =8o)

[sma]

Nur mal so am Rande, wieso interpretiert ihr in "dazu sage ich mal nichts" alle Ablehnung hinein?

Zu sagen, dass man nichts sagen will hat IMHO eine andere Qualität als einfach nichts zu sagen. Ansonsten, ich weiß auch nicht. Freut mich, wenn's nicht so gemeint gewesen ist.

Übrigens, ich musste zwar den Stackless-Ansatz zurückstellen und auch ein post-2.1 Objektmodell (welches ich nicht komplett zu durchdringen imstande bin), aber ich kann jetzt die "Hello World"-Applikation mittels Jetty in Java ausführen :)

Stefan

[Leonidas]

Achja, zum Thema Bytecode gibt es auch PJEs BytecodeAssembler, mit dem kann man sich Bytecode erstellen lassen kann um deinen Interpreter zu testen. Auch total sinnlosen, den CPython nicht ausgeben würde.

[sma]

Nett, danke für den Tipp.

Gibt es eigentlich (vielleicht im PyPy-Projekt) einen komplett in Python geschriebenen Python-Compiler, der den identischen Bytecode erzeugt wie der in CPython eingebaute Compiler? So etwas bräuchte ist später irgendwann mal, um "selfhosting" zu sein.

Stefan

[jens]

Vielleicht ist http://dalkescientific.com/Python/python4ply.html interessant in dem Zusammenhang...

[Leonidas]

Vielleicht ist http://dalkescientific.com/Python/python4ply.html interessant in dem Zusammenhang...

Naja, das parst und verarbeitet nur Python-Supersets, ist also eher vergleichbar mit EE. sma parst und verarbeitet Bytecode. Ich hatte im Hinterkopf noch irgendeinen Link zu dem Thema, aber es fällt mir leider nicht mehr ein.

[sma]

Hatte mir python4ply gebookmarkt, um da mal rein zu schauen, aber wenn ich in compile.py sehe, dass sich `compile.py` auf das Standardmodul `compiler` abstützt, könnte auch letzteres reichen, wenn es 100% Python-Code ist. Sieht aber nicht so aus, da z.B. `parser` eingebunden wird, was ein eingebautetes Modul ist.

Nichts desto trotz klingt python4ply nach einem spannenden Projekt.

Stefan

[mitsuhiko]

Gibt es eigentlich (vielleicht im PyPy-Projekt) einen komplett in Python geschriebenen Python-Compiler, der den identischen Bytecode erzeugt wie der in CPython eingebaute Compiler? So etwas bräuchte ist später irgendwann mal, um "selfhosting" zu sein.

Es gibt das "compiler" Modul von dem aber der Parser in C geschrieben ist. Den müsstest du halt ersetzen. Das compiler Modul ist aber deprecated.