DseWiki: PyPy

Veränderung (letzte Änderung) (Korrektur, Normalansicht)

Verändert: 1,4c1,14

Dies ist eine Implementierung von Python in Python selbst. Das Projekt wurde erst Anfang
2003 begonnen und ist dementsprechend noch lange nicht fertig, aber extrem vielversprechend.
Einen funktionierenden Interpreter, wenn auch auf einer Untermenge von Python, existiert
bereits.

Dies ist eine Implementierung von Python in Python selbst. Ziel ist einerseits die völlige
Loslösung von C, in dem heute der "eigentliche" Python-Interpreter implementiert ist, gleichzeitig
aber auch die Generierung von C- und Maschinencode zur Laufzeit eines PyPy-Programmes.
Letzteres soll z.B. durch Spezialisierungstechniken von Psyco erreicht werden.

Klappt alles, dann bekommt man ein Python, dessen Kern wesentlich kleiner und das insgesamt
weit flexibler und modularer ist als das "normale" Python. Damit ließe sich z.B. Software für
sehr kleine Geräte (embedded devices) in einer portablen Hochsprache entwickeln und
auch einfacher auf mehrere CPUs verteilen, ob im selben oder auf verschiedenen Rechnern.
Weitere Möglichkeiten findet man im OSCON-Bericht unten.

Das Projekt wurde erst Anfang 2003 begonnen und ist dementsprechend noch lange nicht
fertig, aber extrem vielversprechend. Einen funktionierenden Interpreter, wenn auch auf einer
Untermenge von Python, existiert bereits.

Hinzugefügt: 6a17,18

* Erster Bericht zur OSCON 2003,

http://codespeak.net/pypy/index.cgi?doc/oscon2003-paper.html
* Psyco,

http://psyco.sourceforge.net/

Klappt alles, dann bekommt man ein Python, dessen Kern wesentlich kleiner und das insgesamt weit flexibler und modularer ist als das "normale" Python. Damit ließe sich z.B. Software für sehr kleine Geräte (embedded devices) in einer portablen Hochsprache entwickeln und auch einfacher auf mehrere CPUs verteilen, ob im selben oder auf verschiedenen Rechnern. Weitere Möglichkeiten findet man im OSCON-Bericht unten.

Das Projekt wurde erst Anfang 2003 begonnen und ist dementsprechend noch lange nicht fertig, aber extrem vielversprechend. Einen funktionierenden Interpreter, wenn auch auf einer Untermenge von Python, existiert bereits.

Projekt Homepage, http://codespeak.net/pypy/
Erster Bericht zur OSCON 2003, http://codespeak.net/pypy/index.cgi?doc/oscon2003-paper.html
Psyco, http://psyco.sourceforge.net/

Diskussion

Frage: Wozu? Ist das nur ein interessante sportliche Herausforderung oder hat es einen praktischen Zweck?

: Dazu gibt es Antworten in comp.lang.ruby, unter dem Thread Ruby in Ruby. Auch Ruby-Fans würden liebend gerne den Anteil Ruby-Code im Interpreter erhöhen. Es gibt einige Vorbilder: Ein Lisp-Interpreter in SpracheLisp oder SqueakSmalltalk, dessen Interpreter in einer einfach nach C übersetzbaren Untermenge von SpracheSmalltalk geschrieben ist.
: Die Gründe sind z. T. ähnlich wie bei der Frage nach der IDE. Die IDE von VisualWorks oder der Smalltalk RefactoringBrowser sind in Smalltalk geschrieben. Sicher betrachten es Java-Jünger als Vorteil, dass Eclipse in SpracheJava programmiert ist. Ein Vorteil ist offensichtlich: Ich brauche zur Verbesserung und Fehlersuche nur noch in einer Sprache fit zu sein und kann zum Debuggen meiner Anwendung die gleichen Werkzeuge verwenden wie zur Analyse des Entwicklungs- oder Laufzeitsystems.
: Warum gibt es jedoch Leute, die GUI-Toolkits nicht direkt, sondern über ein Binding zu einer Skriptsprache verwenden? Warum ist ein Großteil des Emacs in Lisp geschrieben, warum ist die Skriptsprache von Word nicht C#? Weil Skriptsprachen i. d. R. einfacher zu handhaben sind. So wie ein Ruby-Programmierer laufzeitkritische Routinen in C-Module auslagert, kann umgekehrt ein C++-Entwickler die GUI als für die Laufzeit unkritische Komponente betrachten und sich durch das Auslagern mehr Entwicklungskomfort durch den wegfallenden Compile- und Linkzyklus erkaufen. --SaschaDördelmann

KategoriePython