Cpython? Unglaublich?!!

[Lufia]

Hallo zusammen,

kürzlich hat ein Bekannter auf der Arbeit gemeint welche Vorteile er hat seit sein Modell nicht mehr in C sondern in Java (objektorientiert) programmiert ist.

Grundsätzlich vertrete ich ja die Ansicht das die Sprache eher nebensächlich ist und es auf die Programmstruktur, etc. ankommt. Ich bin kein großer Programmierer kann ein bissle C und python und muss bald noch C++ lernen.

Irgendwie ist mir bei dem Gespräch klar geworden wie unglaublich es ist das python in C programmiert ist. Ich als laienhafter C-Programmierer frage mich nun wie ist das möglich?! Ich meine generell kann man abgeleitet sozusagen in C "ohne Probleme" objektorientiert programmieren. Klar kann ich das nicht, aber wenn sich jemand auskennt ist es demnach möglich. Wie kompliziert das im Fall python sein muss! Speicher dynamisch verwalten,... irgendwie lässt mir das keine Ruhe.

Habe ich das so richtig verstanden? Das python ist nicht viel Mehr als ein C-Programm. Blickt da jemand durch wie pyhton in C umgesetzt ist. Also von der Struktur/Aufbau her.

Wenn ich z.B. eine einfache Funktion programmiere wird die vom Interpreter analysiert und in Bytecode umgewandelt. Dieser Code wird dann ausgeführt.

Aber wo kommt die Funktion dazu hin, wie wird sie Gespeichert? Gerade bei Daten, etc. ist ja alles dynamisch, ich kann sogar Funktionen übergeben. Kennt jemand eine Art Sendung mit der Maus Erklärung dazu?

Hoffe so einen Beitrag gab es nicht schon zig mal.

[C4S3]

Hm, da gebe ich dir recht - ich habe mir die Frage auch schon öfters gestellt.
Es gab da im Awaretek-Python-411-Podcast mal ne Ausgabe, die da hieß:"How Python runs". Da wurde das beschrieben. Leider habe ich nur die Hälfte davon mitbekommen.
Der Download/Podcast ist (zumindest für mich) auch seit einiger Zeit nicht mehr erreichbar. Vielleicht kannst du die MP3 ja trotzdem noch wo auftreiben?
www.awaretek.com/python
http://media.libsyn.com/media/awaretek/ ... onRuns.mp3

Ansonsten müssen wir wohl auf die Antworten der Wissenden warten.

[sma]

Das der Python-Interpreter in C geschrieben ist, ist eine Kombination aus Historie und persönlicher Entscheidung von GvR.

Anfang der 90er, als CPython entstand, gab es noch kein Java (1995). Objektorientierung (1981 Smalltalk) und Garbage Collection (Lisp-Systeme der 60er) waren zwar schon erfunden, aber nicht wirklich verbreitet. Auch Turbo-Pascal 5.5, das erstmals objektorientierte Züge zeigte, war AFAIK noch nicht erschienen. Es gab zwar Objective-C (1986) als Versuch, Smalltalk in C nachzubauen und auch C++ (Nachfolger von C-with-classes, eine Kombination von Simula und C, Anfang der 80er) bereits, aber C war einfacher und verbreiteter.

Danach hat niemand ersthaft versucht und geschafft, den funktionierenden Python-Interpreter von Grund auf neu zu schreiben. Aus heutiger Sicht gäbe es in der Tat bessere Sprachen als C, um so ein Projekt zu starten.

Erwähnenswert ist vielleicht, dass es mit PyPy den Versuch gibt, Python in (einem Subset von) Python nachzubauen, um das dann (ähnlich wie Squeak-Smalltalk es macht) in C oder ähnliche Sprachen zu übersetzen und C nur noch als portablen Assembler zu benutzen. Jython und IronPython sind Python-Implementierungen in Java bzw. C#. Meines Wissens gibt im Rahmen von DrScheme (einem Scheme-Lehrsystem) auch ein (Subset von) Python.

Ich gebe dir Recht, es scheint heute archaisch, Speicher selbst zu verwalten und das nicht einem bewährten Laufzeitsystem zu überlassen und Lisp- oder Smalltalk-Systeme wissen das seit mehr als 30 Jahren und mit Java und C# ist das eine Erkenntnis, die langsam auch bei der Mehrzahl der Programmierer angekommen ist. Dennoch ist es halt so, wie es eben ist.

Du fragst, wie der Python-Interpreter funktioniert. Im Prinzip so: Der Quelltext wird eingelesen, in einzelne Wörter zerlegt und dann gemäß der Sprachregeln von Python eingelesen und "verstanden". Das Ergebnis ist eine baumartige Speicherstruktur, die das Programm abbildet und dann in einem Maschinencode für einen speziellen (und virtuellen) Python-Prozessor übersetzt. Außerdem wird in einem schneller einlesbaren Binärformat wieder in eine Datei geschrieben. Der Maschinencode wird dann von dem eigentlichen Interpreter ausgeführt, der im Prinzip ein großes switch-Statement ist und weiß, was bei jedem Befehl (die alle sehr gut auf die Bedürfnisse von Python zugeschnitten sind) zu tun ist. Ein Laufzeitsystem stellt neben der automatischen Speicherverwaltung die ganzen vordefinierten Datentypen und Funktionen zur Verfügung. Abgelegt werden alle Daten in vielen kleinen Speicherbereichen, die letztlich mit malloc() vom Betriebsystem angefordert werden.

Stefan

[Leonidas]

Das der Python-Interpreter in C geschrieben ist, ist eine Kombination aus Historie und persönlicher Entscheidung von GvR.

Es ist aber bischer nicht die schlechteste, denn C ermöglicht es dass der Python-Interpreter sehr portabel ist, da C fast überall kompiliert werden kann. Auch ist noch heute C eine sehr populäre Sprache und man bekommt mit C als portablen Assembler eine ganze Menge Bindings zu allen möglichen Libraries, die auch in C geschrieben sind (was teils auch daran liegt dass C unter Unices sehr dominant ist/war).

Ich gebe dir Recht, es scheint heute archaisch, Speicher selbst zu verwalten und das nicht einem bewährten Laufzeitsystem zu überlassen und Lisp- oder Smalltalk-Systeme wissen das seit mehr als 30 Jahren und mit Java und C# ist das eine Erkenntnis, die langsam auch bei der Mehrzahl der Programmierer angekommen ist. Dennoch ist es halt so, wie es eben ist.

Nun, aber wie wir wissen beharren vor allem C++ Programmierer auf ihrer so hohen Effizienz und whatnot. Dumm nur, dass die Programme dann Speicher leaken

[sma]

Tja, schnell und unvorhersehrbar abstürzen können ist ja auch ein Wert :)

Klar, das Argument, das C so schön portabel und überall verfügbar ist, ist nicht von der Hand zu weisen. Man könnte aber auch C++ oder Objective-C plus einer bewährten GC-Bibliothek einsetzen. Da ja nicht C sondern in der Regel gcc das Ding ist, was so schön portabel ist und der auch die anderen beiden C-Dialekte unterstützt, wären das IMHO Alternativen.

Die andere Idee wäre, auf einer Sprache aufzusetzen, die dann eben für einen den C-Weg geht, man selbst aber von deren höherer Abstraktion profitiert. Hat man nicht versucht (oder sogar geschafft) einen Perl 6-Interpreter in Haskell zu schreiben? Nachteil ist da meist, dass die wenigsten Entwickler mehrere Sprachen und/oder gerade diese "exotische" Sprache beherrschen und man dann befürchtet, nicht genug Mitstreiter zu finden. Also ist es wieder der kleinste gemeinsame Nenner.

Ich könnte mir vorstellen, dass ein Python-Interpreter, der in Squeak-Smalltalk (ebenfalls ein Bytecode-Interpreter) geschrieben wäre, ähnlich schnell wäre und heutzutage wären die 1-2 MB Image-Datei, die das Ding minimal hätte, auch kein größeres Problem mehr. Das Ding könnte man dann sogar mit PyPy übersetzen, wo ein Seitenprojekt versucht (hat), eine Squeak-Smalltalk-VM zu bauen. Der Vorteil von Smalltalk wäre, dass man bereits eine bewährte VM mit einem recht kompatiben Ansatz hätte. Ich wünschte, ich könnte jetzt sagen, dass man dann auch von deren Versuchen, mehrkernfähig, JIT-kompiliert und FFI-fähig zu werden profitieren könnte, doch diese Projekte kommen AFAIK auch nicht so recht voran.

Dinge wie Haskell oder OCaml wären auch denkbar, aber nicht meine unbedingt Welt (seht ihr, da ist das Exotensprachen-Argument). Dann schon lieber Scheme...

Eine durchaus ernsthafte Alternative wäre für mich, wenn ich jetzt einen Python-Interpreter neu schreiben sollte, C#. Ich würde sagen, Mono ist ähnlich portabel wie jedes andere C-Programm auch und man kann von der JIT-Technologie profitieren. Desweiteren wäre das die einzige VM, wo ich vermute, dass es kurzfristig realistisch ist, dynamische Features in die VM zu bringen.

Für Java 7 ist da zwar auch etwas geplant, doch wann das kommt steht ja in den Sternen. Und die Hotspot-VM ist zwar Opensource, doch ich denke nicht, dass da ein Hobby-Entwickler eine Chance hat, in deren keinesfalls triviale Codebasis einzusteigen.

Dann noch eher etwas wie V8 oder SquirrelFishExtreme - beide sind allerdings in C++ geschrieben. Die V8-Codebasis ist dabei noch recht übersichtlich, allerdings speziell auf JavaScript zugeschnitten und das will man auch nicht ändern.

Stefan

[Leonidas]

Klar, das Argument, das C so schön portabel und überall verfügbar ist, ist nicht von der Hand zu weisen. Man könnte aber auch C++ oder Objective-C plus einer bewährten GC-Bibliothek einsetzen. Da ja nicht C sondern in der Regel gcc das Ding ist, was so schön portabel ist und der auch die anderen beiden C-Dialekte unterstützt, wären das IMHO Alternativen.

C hat noch den Vorteil, dass das C-ABI stabil ist und insbesondere sind die einzigen Nutzer von Objective-C auf Mac OS zu finden. Die Zuordnung C -> Unix, Objective-C -> Mac OS und C++ -> Windows gilt immer noch. Ich weiß gar nicht ob ich persönlich nicht C+GLib gegenüber C++ bevorzugen würde, wenn ich gezwungen wäre das zu nutzen.

Dinge wie Haskell oder OCaml wären auch denkbar, aber nicht meine unbedingt Welt (seht ihr, da ist das Exotensprachen-Argument). Dann schon lieber Scheme...

Gleich die zweite(?) Implementation von Python, Vyper war in OCaml geschrieben. Aber es ist eben das Problem, dass es da schwerer ist Mitentwickler zu finden. Ansonsten haben hauptsächlich Funktionale Sprachen metazirkuläre Implementationen, in Scheme ist ist das ja eine Aufgabe vom Kalliber "Hallo Welt"

Übrigens ist es mir nicht bekannt, dass PLT einen Pyhton-Subset beherrschen würde. Hast du da einige Informationen dazu? Ich weiß dass sie Algol 60 und einen Java-Dialekt haben, aber Python wäre mir neu.

[BlackVivi]

Was ich interessant fände:

Python in D implementieren ._. Das wäre nativ... und recht flott. Natürlich keine Vorteile gegenüber der Implementierung in C, aber es wäre echt cool irgendwie. Ich persönliche empfinde D als einen sinnvollen Fortschritt zu C. C++ mochte ich nie besonders. Es wirkte oft ein wenig zusammengeschustert und gezwungen... kompliziert. Wie Java...

Aber bei D hatte ich das Gefühl nich ._. Alleine schon das's sowas gibt wie'ne for-each Schleife mit'n automatischen Datentyp find ich so total sympatisch.

Was die Leute wohl vor D abschreckt: Es ist nicht komplett Open Source. Es gibt zwar GCD und so... aber is ja einfach nich dasselbe wie bei C, C++ usw, wo's halt freie Referenzimplementierungen gibt.

[sma]

Für DrScheme, siehe http://www.ccs.neu.edu/scheme/pubs/scheme2003-ms.pdf. Außerdem gibt es offenbar noch http://common-lisp.net/project/clpython/. Bei beiden Systemen kann ich nicht sagen, ob sie die ganze "underunder"-Magie unterstützen, die Python erst Laufzeitsystem her komplex und gleichzeitig eine Implementierung langsamer machen.

Von Vyper wusste ich gar nichts. Spannend. Siehe auch http://www-128.ibm.com/developerworks/l ... pyth7.html. Der Quelltext, den gefunden habe, ist von 2000. Damit wäre JPython, wie es damals noch hieß, älter.

Was bietet D gegenüber anderen Sprachen für einen Vorteil?

Übrigens: Hätten sich mehr Projekte Ende der 80er und Anfang der 90er für Objective-C entschieden, wäre das jetzt vielleicht nicht nur eine Sprache für OS X, sondern das, woran die Leute bei C und Objektorientierung zuerst denken würden. Hat nicht sein sollen.

Das mit der Metazirkularität der funktionalen Sprachen kommt IMHO daher, dass sie sowohl einfacher als auch ausdrucksstärker sind und daher die Aufgabe einfacher ist. PyPy als metazirkuläres Python ist da von einem ganz anderen Kaliber und wirkt so komplex, dass ich bislang noch nie Lust hatte, mich durch den ganzen Quelltext zu graben.

Stefan

[BlackVivi]

Was bietet D gegenüber anderen Sprachen für einen Vorteil?

Wird nativ in richtigen Maschinencode kompiliert, braucht also keine VM oder so ._. Und hat Objektoriertung, ein wenig dynamische Typisierung, einen GC (der sogar nur optional ist)... Sogar Aspekte aus der funktionalen Programmierung ^__^ Es ist sogar teilweise schneller als C... in manchen unerheblichen Algorithmen... Weil's leichter zu programmieren ist. Hat halt nich diesen "compile once - run everywhere"-Vorteil, aber die Standardbibliothek ist auch total portabel... Bietet halt viel Komfort von neueren Sprachen mit einigen Vorteilen von Ansi-C.

Ich hab mal ein bisschen was damit programmiert... Man kann halt auch C-Bibliotheken damit benutzen und so. Ich glaube Python in D würde... ganz cool sein. Es wäre leichter zu erweitern, zumindest für mich >_<

[HWK]

Ich finde D durchaus auch interessant. Es hat ja einige Annehmlichkeiten von Python bei fast der Geschwindigkeit von C. Siehe auch diesen Thread.
MfG
HWK

[Leonidas]

D war doch die Sprache mit den zwei konkurrierenden Stdlibs (Tango und.. ich glaub das andere hatte keinen Namen) und den unausgereiften Compilern?

Für so Verrückte wie mich wäre eher BitC interessant, wie es scheint das funktionale Equivalent zu D. Momentan nutzt es noch S-Expressions, später wollen die davon weg

[lunar]

Übrigens: Hätten sich mehr Projekte Ende der 80er und Anfang der 90er für Objective-C entschieden, wäre das jetzt vielleicht nicht nur eine Sprache für OS X, sondern das, woran die Leute bei C und Objektorientierung zuerst denken würden. Hat nicht sein sollen.

Glücklicherweise ...

[cofi]

D war doch die Sprache mit den zwei konkurrierenden Stdlibs (Tango und.. ich glaub das andere hatte keinen Namen) und den unausgereiften Compilern?

Phobos ist die andere. Zu den Compilern kann ich nichts sagen, da ich die Sprache zwar sehr interessant finde, aber noch nicht dazu kam etwas damit zu machen

[BlackVivi]

D war doch die Sprache mit den zwei konkurrierenden Stdlibs (Tango und.. ich glaub das andere hatte keinen Namen) und den unausgereiften Compilern?

Unausgereift o_o? Wieso ._.

[Leonidas]

Unausgereift o_o? Wieso ._.

Also ich habe durchaus Leute über die Compiler meckern hören, weiß aber nicht ob es DMD oder GDC war.

[BlackJack]

@Leonidas: Phobos, die Bibliothek vom D-Erfinder, fühlt sich eher wie C an, also mehr Funktionen als Klassen, während Tango mehr in Richtung C++ geht und mehr über Klassen löst. Allerdings nicht alles, also nicht so extrem wie bei Java.

Das Problem ist, dass Phobos und Tango nicht so ganz kompatibel sind, weil in Phobos auch die Laufzeitbibliothek der Sprache steckt. Also kann man sich nur entscheiden eine der beiden Bibliotheken zu verwenden. Bei D 2.0 wird die Laufzeitbibliothek in eine eigene Bibliothek rausgezogen.

[BlackVivi]

@Leonidas: Phobos, die Bibliothek vom D-Erfinder, fühlt sich eher wie C an, also mehr Funktionen als Klassen, während Tango mehr in Richtung C++ geht und mehr über Klassen löst. Allerdings nicht alles, also nicht so extrem wie bei Java.

Phobos is auch viel besser, finde ich. Tango wirkt ein wenig... kompliziert des kompliziert seins wegen.... So wie C++-Programmierer manchmal sind.

Naja, mit D 2.0 kann man beide Bibltiotheken quasi parallel nutzen, wegen dem eben genannten.

[OverNord]

Unausgereift o_o? Wieso ._.

Also ich habe durchaus Leute über die Compiler meckern hören, weiß aber nicht ob es DMD oder GDC war.

Ich hab mal irgendwo gelesen das GDC noch recht unausgereift sei. Über DMD kann ich mich persönlich nicht beschweren.

[sma]

Ob A, B, C oder D. Egal. Wie helfen diese Sprachen konkret, einen Python-Interpreter im Vergleich zum Original zu schreiben? Ich habe kurz auf die Seite von D geschaut und keine detaillierten Informationen zum D-GC gefunden. Ist dieser "state of the art" und vergleichbar zu dem, was in der JVM steckt? Ist es ein konservativer oder ein exakter GC? Welche Algorithmen benutzt er? Ist er threadsafe? Die Güte des GC wäre aber IMHO ein wesentlicher Faktor. Bei Java weiß ich, dass er gut ist. Bei Squeak als Basis wäre er auch okay. Ebenso bei C#.

Klammern wir einmal das Problem, Python-Quelltext zu lesen, zu parsen und in einen abstrakten Syntaxbaum umzuwandeln aus. Wie sähe die Repräsentation der Python-Objekte im Laufzeitsystem aus? Wie sähe der Bytecode-Interpreter aus? Könnte man einen JIT der implementierenden Sprache nutzen? Was kostet Laufzeit? Was spart sie? Welchen Overhead hätte man - wenn überhaupt - gegenüber der C-Version?

In Java könnte ein Ausschnitt so aussehen:

Code: Alles auswählen

abstract class PyValue {
    public PyStr __str__(PyRuntime rt) {
        throw UnsupportedOperationException();
    }
}

class PyInt extends PyValue {
    private int value;
    
    public PyStr __str__(PyRuntime rt) {
        new PyStr(String.valueOf(value));
    }
}

class PyStr extends PyValue {
    private String value;
    
    public PyStr __str__(PyRuntime rt) {
        return this;
    }
}

class PyInstance extends PyValue {
    private PyClass __class__;
    private PyDict __dict__;
    
    public PyStr __str__(PyRuntime rt) {
        PyValue v = __class__.__str__method;
        if (v != null) {
            return v.__call__(rt);
        }
        return __repr__(rt);
    }
}

Ich nutze Unterklassen einer abstrakten Oberklasse PyValue, um alle Objekte zu repräsentieren. PyValue kennt alle wesentlichen Methoden - ein Workaround, damit ich bei Java nicht laufend casten muss. Mein Ansatz ist übrigens zu naiv für Python > 1.5. Dort muss man auch noch die Metaebene modellieren. Jede Funktion wie __str__ wird da zu einer Klasse. Dafür könnte man in Java aus dem AST direkt Java-Bytecode erzeugen und von dem JIT der JVM profitieren.

Nachteil ist, dass man überall und in wirklich jeder Methode eine Referenz auf das Laufzeitsystem mitschleppen muss, wo Frame-Objekte verwaltet werden, damit man auf globals() und locals() zugreifen kann. Diese Frames kosten extrem Zeit und hier wäre eine Unterstützung durch das Java-Laufzeitsystem hilfreich - geht natürlich nicht, weil man an deren Stackframes nicht heran kommt.

Stefan

[BlackJack]

@sma: Ich denke nicht, dass sich BlackVivi so tiefgreifende Gedanken darüber gemacht hat. Der Gedankengang ist eher: D ist fast wie C, dass heisst es sollte nicht sooo schwer sein, den aktuellen C-Quelltext nach D zu portieren. Wie schwer das wirklich ist, wage ich nicht abzuschätzen, denn der Teufel steckt da sicher im Detail.

Und dann könnte man theoretisch anfangen den "fast C"-D-Quelltext einfacher zu gestalten, in dem man die Spracheigenschaften von D ausnutzt, wie zum Beispiel Objektorentierung, dass "Dictionaries" in der Sprache schon vorhanden sind usw.

Der GC ist implementierungsabhängig, AFAIK benutzt der `gdc` den Boehm-GC.