Python 3.0 und alte Frameworks
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Y0Gi hat geschrieben:Eben der übliche Vorteil bei quasi-monolithischen Systemen
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.Guter Einwand. Ich sehe nur das Problem, dass einfach die Basis - zumindest in der Unix-Welt - fehlt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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.Y0Gi hat geschrieben:Guter Einwand. Ich sehe nur das Problem, dass einfach die Basis - zumindest in der Unix-Welt - fehlt.
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
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.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.
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?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
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
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
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.sma hat geschrieben:Wahrscheinlich sind wir in der "Gut genug ist der schlimmste Feind von Gut"-Situation.
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.
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.
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.
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.
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.
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.
Sogar Google verwendet noch zum teil 2.2.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.
http://panela.blog-city.com/python_at_g ... dforum.htm
- cofi
- Python-Forum Veteran
- Beiträge: 4432
- Registriert: Sonntag 30. März 2008, 04:16
- Wohnort: RGFybXN0YWR0
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.
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.
-
- User
- Beiträge: 1790
- Registriert: Donnerstag 28. Oktober 2004, 16:33
- Wohnort: Graz, Steiermark - Österreich
- Kontaktdaten:
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.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
TUFKAB – the user formerly known as blackbird