Das deutsche Python-Forum

Eben der übliche Vorteil bei quasi-monolithischen Systemen

Y0Gi hat geschrieben:Eben der übliche Vorteil bei quasi-monolithischen Systemen

Ja, stimmt. Die Portierung macht auch noch einige Probleme aber wenn sie mal da ist wird sie der Adaptation von Python 3 einen wohl ziemlich beträchtlichen Schub geben. Daher bin ich insbesondere gespannt wie es bei Django weitergeht.

Guter Einwand. Ich sehe nur das Problem, dass einfach die Basis - zumindest in der Unix-Welt - fehlt.

Guter Einwand. Ich sehe nur das Problem, dass einfach die Basis - zumindest in der Unix-Welt - fehlt.

Momentan ja, aber das nächste Ubuntu wird 2.6 und 3.0 mitbringen, selbiges gilt für Fedora. Problematischer ists da bei Debian, das in Lenny nur mit 2.5 kommt und so weder die Vorwärtskompatibilität bietet noch "The Real Thing", 3.0. Aber vielleicht ist ja dann bei Lenny+1 3.0 ja schon etabliert. Das ist wichtig, weil eben Debian für Server gerne eingesetzt wird. Da müsste man dann in dieser Zeit auf Backports zurückgreifen was natürlich nicht ganz so optimal ist.

Y0Gi hat geschrieben:Guter Einwand. Ich sehe nur das Problem, dass einfach die Basis - zumindest in der Unix-Welt - fehlt.

Bei Python mag das anders sein, aber ansonten würde ich mal sagen, die Unix-Welt ist eher egal. Wer sich für Python interessiert und Windows nutzt, wird sich die aktuelle Version 3.0 laden und damit beginnen. Sobald er (oder sie) bemerkt, dass viele Bibliotheken nicht funktioniert, gibt es zwei Möglichkeiten: Wechsel auf eine ältere Version oder wechsel zu einer anderen Programmiersprache. Ich würde wahrscheinlich den zweiten Weg gehen.

Hey, selbst Rails hat es inzwischen geschafft, auf Ruby 1.9 lauffähig zu sein und statt die gute alte Zeit zu beschwören, beschwören dort Leute wie Dave Thomas die Community, Gems 1.9 kompatibel und so den Fortschritt möglich zu machen.

Übrigens: Django macht es sich mit seiner Rückwärtskompatibilität bis 2.3 auch nicht gerade einfacher, auf 3.0 portiert werden zu können. Ich denke, man muss das System letzlich branchen, alle alten Zöpfe abschneiden und sauber auf 3.0 aufsetzen. An sonsten wird dieses str/unicode-Gehühnere entgültig undurchschaubar.

Stefan

sma hat geschrieben:Hey, selbst Rails hat es inzwischen geschafft, auf Ruby 1.9 lauffähig zu sein und statt die gute alte Zeit zu beschwören, beschwören dort Leute wie Dave Thomas die Community, Gems 1.9 kompatibel und so den Fortschritt möglich zu machen.

Wenn ich den Zeitraum seitdem Ruby 1.9 released ist mit dem Zeitraum seitdem Python 3.0 released ist vergleiche wundere ich mich da auch eher wenig.

Wobei Ruby andererseits auch User verloren hat wegen der katastophalen Release-Politik. 2.x ewig hinauszögern, dann 1.9 dann 1.9.1 und gleichzeitig inkompatible Änderungen am 1.8.x-Branch?

Matz und Co haben sich sicherlich bei der Release-Planung und Weiterentwicklung von Ruby nicht gerade mit Ruhm bekleckert. Wurde auf der Ruby-Conf auch von Dave Thomas in seiner Keynote süffisant kritisiert.

Die Situation von Python ist da eigentlich besser: Seit Jahren steht fest, das Python 3.0 kommen wird und auch der Feature-Umfang ist doch seit mindestens zwei Jahren bekannt. Dennoch sind jetzt auf einmal alle Leute total verwundert. Ich hätte gedacht, die lange Test und Entwicklungszeit wäre genau der Zeitraum gewesen, die existierenden Projekte fit für 3.0 zu machen.

Ich glaube ja, Python 3.0 ist einfach nicht so viel besser als Python 2.x, sodass der Aufwand des Umstiegs nicht lohnenswert genug erscheint. Vielleicht war man zu konservativ, was die neuen Features anging? Vielleicht hat man zu sehr die Probleme beim Umstieg befürchtet und daher erst zu Problemen beim Umstieg gemacht? Wahrscheinlich sind wir in der "Gut genug ist der schlimmste Feind von Gut"-Situation.

Stefan

sma hat geschrieben:Wahrscheinlich sind wir in der "Gut genug ist der schlimmste Feind von Gut"-Situation.

Naja, es gibt schon ein paar schöne Dinge in 3.0 ... ich persönlich würde auch sofort umsteigen. Aber das Problem ist eben, dass außer lxml eigentlich kaum ein Projekt vollständig portiert ist, vor allem bei kleineren Modulen sieht die Situation ziemlich düster aus.

De facto ist das für mich eine rationale Entscheidung: Der Aufwand, zum jetzigen Zeitpunkt Code vollständig zu portieren, überwiegt die Vorteile von Python 3k halt einfach.

Aber früher oder später wird 3k schon kommen. Und wenn es halt ein bisschen später ist ... mein Gott, die Zeit bis dahin werden wir auch noch überstehen.

Außerdem solltest du als Java-Entwickler laaaaaannnnge Umstiegsperioden doch gewöhnt sein

Ich hatte nicht den Eindruck, das die Python-Entwickler erwartet haben, dass viel vor der Veröffentlichung von Python 3.0 portiert wird. Soweit ich das verstanden habe, soll 2.6 als Ausgangspunkt für eine Portierung dienen, und das ist noch nicht so lange draussen. Bei Python 3.0 wurde explizit kein Wert auf Geschwindigkeit gelegt, sondern mehr auf Feature-vollständigkeit.

Ein vorgeschlagener Portierungsweg ist, die 2.6 zu verwenden und den Code soweit anzupassen, dass das `2to3.py`-Programm eine lauffähige 3.0er Variante des Projekts automatisch erstellen kann, so dass man nur eine Quelltextbasis für 2.6 pflegen muss, aber trotzdem das Projekt auch für 3.0 anbieten kann.

Dazu muss sich aber 2.6 auch erst einmal durchsetzen. Ich setze jedenfalls erst 100% darauf, wenn meine Linux-Distribution das als reguläres Paket anbietet. Bin mittlerweile nämlich faul geworden und habe keine Lust alle Zusatzpakete, die ich mir heute einfach per `apt-get` holen kann, von Hand zu installieren.

Die Leute sind halt doch etwas geschockt, solche Änderungen gibt es ja normalerweise nicht.

Ich persönlich finde es einfach nur geil. Vielleicht sammeln die Pythonentwickler durch diesen Umstieg genügend Erfahrung, sodass man solche Reinigungen alle 5 Jahre vornehmen kann.

bremer hat geschrieben:Die Leute sind halt doch etwas geschockt, solche Änderungen gibt es ja normalerweise nicht.

Klar die Änderungen sind ja auch erst seit 2 Wochen bekannt.

Aber in der Praxis wäre eine frühe Vorbereitung auf diese Änderungen einfach nicht rational gewesen. Warum sollte ein Projekt, dass auf andere Projekte angewiesen ist, als erstes beginnen, den Code zu überführen?

Die Katze beißt sich selbst in den Schwanz.

Mit Python 2.6 und 2.7 gibt und wird es zwei Major-Releases geben, die den Weg zu Py3k ebnen. Solange die aber noch nicht flächendeckend deployed werden (können) ist 2.4+1 aktuell und nicht 2.5+1.

Die Änderungen in Py3k sind seit ewigen Zeiten bekannt (und sinnvoll; andere Programmiersprachen haben ihre Schwächen über Jahre in sich hineingefressen anstatt sie auszumerzen) und das ist gut so. Die Transition wird trotzdem erst langsam Fahrt aufnehmen, da kann man sich noch gut mindestens einige Monate zurücklehnen und abwarten, bevor man in Panik ausbrechen muss.

Anbieter von Python-Paketen wurden und werden früh genug gebeten, den Code aufwärtskompatibel zu machen und kommen mittelfristig wohl nicht umher, zumindest 2.6 zu berücksichtigen. Auf eine breite Palette an Py3k-Pakete hoffe ich aber erst, wenn 2.6 umfassend Einzug gehalten und selbst dann noch ein halbes Jahr oder mehr ins Land gegangen sind.

Wer neue Projekte beginnt, kann das gut mit 2.6 tun. Dafür sollte es in absehbarer Zeit die populärsten Pakete geben (oder man kompiliert im Falle von Erweiterungen in C eben selbst) und der Umstieg auf Py3k ist dann nur noch ein kleiner Schritt.

Ich glaube ja, Python 3.0 ist einfach nicht so viel besser als Python 2.x, sodass der Aufwand des Umstiegs nicht lohnenswert genug erscheint. Vielleicht war man zu konservativ, was die neuen Features anging? Vielleicht hat man zu sehr die Probleme beim Umstieg befürchtet und daher erst zu Problemen beim Umstieg gemacht? Wahrscheinlich sind wir in der "Gut genug ist der schlimmste Feind von Gut"-Situation.

Sogar Google verwendet noch zum teil 2.2.

http://panela.blog-city.com/python_at_g ... dforum.htm

Der Blogeintrag ist von 2006, da war Python 2.2 zwar auch schon 3 Jahre alt, aber so tragisch ist das auch nicht
Ich nehm mal an die sind da jetzt weiter, v.a. im Zuge mit den AppEngines .. aber wär mal interessant da frische Infos zu haben.

Hyperion hat geschrieben:Weiß jemand, wie es bei werkzeug aussieht? Sind da schon PLäne in Richtung Py3k? Afaik käuft ja mod-wsgi schon auf Py3k, wäre also demnach für werkzeug schon ein Anreiz imho

Jinja2 wird als erstes portiert, Werkzeug sobald die WSGI spec für Python 3 stable ist und es erste Systeme gibt, die das unterstützen. Das momentan erste und auch einzige ist mod_wsgi und halt der wsgiref Server.

Wobei der wsgiref-Server unter Py3k ja noch kaputt ist.