Was sind die Nachteile von Stackless Python? [geschlossen]

Ich habe kürzlich über Stackless Python gelesen und es scheint viele Vorteile gegenüber Vanille-cPython zu haben. Es hat all diese coolen Funktionen wie unendliche Rekursion, Mikrothreads, Fortsetzungen usw. und ist gleichzeitig schneller als cPython (etwa 10%, wenn man das Python-Wiki glaubt) und damit kompatibel (mindestens die Versionen 2.5, 2.6) und 3.0).

All dies sieht fast zu gut aus, um wahr zu sein. Allerdings TANSTAAFL , sehe ich nicht viel Begeisterung für Stackless unter der Python - Community, und PEP 219 hat sich nie in Realisierung. Warum ist das so? Was sind die Nachteile von Stackless? Welche Skelette sind in Stackless 'Schrank versteckt?

(Ich weiß, dass Stackless keine echte Parallelität bietet, sondern nur eine einfachere Art der gleichzeitigen Programmierung. Es stört mich nicht wirklich.)

Ich weiß nicht, woher das "Stackless ist 10% schneller" im Wiki stammt, aber andererseits habe ich nie versucht, diese Leistungszahlen zu messen. Ich kann mir nicht vorstellen, was Stackless tut, um einen so großen Unterschied zu machen.

Stackless ist ein erstaunliches Werkzeug mit mehreren organisatorischen / politischen Problemen.

Der erste stammt aus der Geschichte. Christian Tismer begann darüber zu sprechen, was vor etwa 10 Jahren schließlich stapellos wurde. Er hatte eine Vorstellung davon, was er wollte, aber es fiel ihm schwer zu erklären, was er tat und warum die Leute es benutzen sollten. Dies liegt zum Teil daran, dass sein Hintergrund nicht über das CS-Training für Ideen wie Coroutinen verfügte und dass seine Präsentationen und Diskussionen sehr implementierungsorientiert sind, was für jeden, der noch keine Erfahrung in der Fortsetzung hat, schwer zu verstehen ist, wie man es als Lösung verwendet Ihre Probleme.

Aus diesem Grund war die Erstdokumentation schlecht. Es gab einige Beschreibungen zur Verwendung, wobei die besten von Drittanbietern stammen. Auf der PyCon 2007 hielt ich einen Vortrag über " Using Stackless ", der laut den PyCon-Umfragewerten recht gut ankam. Richard Tew hat großartige Arbeit geleistet , diese gesammelt , stackless.com aktualisiert und die Distribution beibehalten, wenn neue Python-Versionen erscheinen. Er ist Mitarbeiter von CCP Games , Entwickler von EVE Online, das Stackless als wesentlichen Bestandteil seines Spielesystems verwendet.

CCP-Spiele sind auch das größte reale Beispiel, das Menschen verwenden, wenn sie über Stackless sprechen. Das Haupt-Tutorial für Stackless ist Grant Olsons " Einführung in die gleichzeitige Programmierung mit Stackless Python ", das ebenfalls spielorientiert ist. Ich denke, dies gibt den Leuten eine verzerrte Vorstellung davon, dass Stackless spielorientiert ist, wenn es mehr darum geht, dass Spiele leichter fortlauforientiert sind.

Eine weitere Schwierigkeit war der Quellcode. In seiner ursprünglichen Form erforderte es Änderungen an vielen Teilen von Python, was Guido van Rossum, den Python-Anführer, vorsichtig machte. Ich denke, ein Teil des Grundes war die Unterstützung für call / cc, die später entfernt wurde, weil sie "zu sehr der Unterstützung eines goto ähnelt, wenn es bessere übergeordnete Formulare gibt". Ich bin mir über diesen Verlauf nicht sicher. Lesen Sie diesen Absatz einfach als "Stapellos erforderte früher zu viele Änderungen."

Spätere Versionen erforderten keine Änderungen, und Tismer drängte weiterhin auf die Aufnahme in Python. Obwohl einige Überlegungen angestellt wurden, ist die offizielle Haltung (soweit ich weiß), dass CPython nicht nur eine Python-Implementierung ist, sondern auch als Referenzimplementierung gedacht ist und keine stapellose Funktionalität enthält, da es von Jython nicht implementiert werden kann oder Iron Python.

Es gibt absolut keine Pläne für " wesentliche Änderungen an der Codebasis ". Das Zitat und der Referenz-Hyperlink von Arafangion (siehe Kommentar) stammen aus dem Jahr 2000/2001. Die strukturellen Veränderungen sind seit langem durchgeführt worden, und das habe ich oben erwähnt. Stackless wie es jetzt ist, ist stabil und ausgereift, mit nur geringfügigen Änderungen an der Codebasis in den letzten Jahren.

Eine letzte Einschränkung bei Stackless - es gibt keinen starken Befürworter für Stackless. Tismer ist jetzt tief in PyPy involviert , eine Implementierung von Python für Python. Er hat die Stackless-Funktionalität in PyPy implementiert und hält sie für viel besser als Stackless selbst und ist der Meinung, dass PyPy der Weg der Zukunft ist. Tew behauptet Stackless, aber er interessiert sich nicht für Anwaltschaft. Ich überlegte, in dieser Rolle zu sein, konnte aber nicht sehen, wie ich damit ein Einkommen erzielen könnte.

Wenn Sie in Stackless trainieren möchten, können Sie mich gerne kontaktieren ! :) :)

Es dauerte ziemlich lange, diese Diskussion zu finden. Zu dieser Zeit war ich nicht auf PyPy, sondern hatte eine 2-jährige Affäre mit Psyco, bis die Gesundheit dies alles ziemlich plötzlich aufhörte. Ich bin jetzt wieder aktiv und entwerfe einen alternativen Ansatz - werde ihn auf EuroPython 2012 präsentieren.

Die meisten Andrews-Aussagen sind richtig. Einige kleinere Ergänzungen:

Stackless war vor 10 Jahren deutlich schneller als CPython, da ich die Interpreter-Schleife optimiert habe. Zu diesem Zeitpunkt war Guido noch nicht dazu bereit. Einige Jahre später haben die Leute ähnliche und noch mehr und bessere Optimierungen vorgenommen, was Stackless erwartungsgemäß etwas langsamer macht.

Zur Aufnahme: Nun, am Anfang war ich sehr aufdringlich und überzeugt, dass Stackless der richtige Weg ist. Später, als es fast möglich war, aufgenommen zu werden, verlor ich das Interesse daran und zog es vor, es so zu lassen, teilweise aus Frustration, teilweise um die Kontrolle über Stackless zu behalten.

Die Argumente wie "andere Implementierungen können es nicht" fühlten sich für mich immer lahm an, da es andere Beispiele gibt, bei denen dieses Argument ebenfalls verwendet werden könnte. Ich dachte, ich vergesse das besser und bleibe in guter Freundschaft mit Guido und habe meine eigene Distribution.

Inzwischen ändern sich die Dinge wieder. Ich arbeite an PyPy und Stackless als Erweiterung. Ich werde manchmal später darüber sprechen

Prost - Chris

Wenn ich mich richtig erinnere, sollte Stackless in das offizielle CPython aufgenommen werden, aber der Autor von stackless forderte die CPython-Leute auf, dies nicht zu tun, da er einige wesentliche Änderungen an der Codebasis vornehmen wollte - vermutlich wollte er die Integration später, wenn Das Projekt war reifer.

Die Antworten hier interessieren mich auch. Ich habe ein bisschen mit Stackless gespielt und es sieht so aus, als wäre es eine gute, solide Ergänzung zu Standard-Python.

In PEP 219 werden mögliche Schwierigkeiten beim Aufrufen von Python-Code aus C-Code erwähnt, wenn Python auf einen anderen Stapel wechseln möchte. Es müsste Möglichkeiten geben, dies zu erkennen und zu verhindern (um zu vermeiden, dass der C-Stapel weggeworfen wird). Ich denke, das ist nachvollziehbar, deshalb frage ich mich auch, warum Stackless für sich allein stehen muss.