Soweit ich weiß haben die Autoren von Unladen Swallow einige Patches eingeschickt, müsste man in Python-Bugtracker schauen, wie da der Status ist.
Und für Python 3.0 wird nichts mehr eingeführt, da das offiziell tot ist Du meinst sicher 3.x und ja, das sollte möglich sein, da die Änderungen am Interpreter selbst ja nicht so groß sind (mehr Unicode und Wegfall der Old-Style-Klassen). Google ist nur momentan nicht an 3.x interessiert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Okay, das freut mich zu hören. Unladen Swallow's Ziel ist nach ihren eigenen Aussagen ja bis zur 5x mal schnellere Ausführungszeit, momentan sind sie aber noch bei 25% am rumwerkeln . Wird das in Q32009 (Quartel 3) wesentlich verbessert - kann man da also mit den ganzen Optimierungen rechnen?
Der Projektplan sagt, Q3 2009 wird's besser. Wo das aber herkommen soll, muss man noch mal sehen. Zur Zeit haben die ja noch das Problem, dass der LLVM-JIT deutlich mehr Zeit kostet, als er wieder einspart, sich also nur bei langlaufenden Serverprozessen wirklich lohnt.
MacRuby nutzt ja ebenfalls LLVM und hat "awesome" Performance gegenüber YARV (Ruby 1.9.x) und JRuby verkündet, was prompt einen Rant des JRuby-Macher beschworen hat, in dem er glaubhaft darlegt, dass es zwar einfach ist, fib(n) schnell zu machen, das aber wenig praxisrelevant ist und gerade Ruby echt fiese Performance-Bremsen im Sprachdesign hat.
Aber man sollte die Hoffnung nicht aufgeben.
Ich denke ja, man könnte ein verschlanktes "Server-Python" basierend auf der Syntax von Python 3.1 aber mit weniger "Metamagie" auf der Java-Plattform (JDK 7) performant und vor allen Dingen "threadsafe" ohne GIL hinbekommen. Die Frage ist nur, ob es den Aufwand wert ist, oder ob man nicht einfach ein paar mehr Rechner mit mehr Hauptspeicher aufstellt und es auch gut ist.
Leonidas hat geschrieben:Hmm? Das ist seltsam, denn obwohl Vista keine bahnbrechenden Veränderungen hat, ist Windows 7 schon jetzt erfolgreich.
Der Erfolg von MS beruht sicher auch darauf, dass der Umstieg von Produkt xy1 nach xy2 immer relativ schmerzfrei ist. By Py3 bezogen auf Py2 ist das nicht der Fall. Und wenn schon, sollte doch pain/gain deutlich kleiner als 1 sein. Einem Kaufmann zu erklaeren - es muessen 100 Skripte geaendert werden, kostet ein bis zwei Mannmonate, bringt aber eigentlich nichts - ist nun mal schwierig. Selbst im non kommmerziellen Bereich tut man sich schwer Zeit in irgendwas zu stecken, ohne davon zu profitieren.
Ich denke, man wird bei Py3 schon noch einen Joker aus dem Aermel holen muessen, um Leute zum Umsteigen zu motivieren.
Du meinst sicher 3.x und ja, das sollte möglich sein, da die Änderungen am Interpreter selbst ja nicht so groß sind (mehr Unicode und Wegfall der Old-Style-Klassen). Google ist nur momentan nicht an 3.x interessiert.
. Wird das in Q32009 (Quartel 3) wesentlich verbessert - kann man da also mit den ganzen Optimierungen rechnen?
