Das deutsche Python-Forum

Erwin hat geschrieben:Tulpel, stimmt.

Falsch, es hat nichts mit Tulpen zu tun - es heißt Tupel. Und das andere sind nicht Listings oder Arrays sondern Listen.

Erwin hat geschrieben:Ob man vielleicht eine Zusammenfassung erstellen kann, über die Veränderungen?
Und zwar im Positiven Sinne.
Wo man also vor allem die Vorteile hervorhebt?

Es wird ein "What's New in Python 3.0" geben, so wie es für die Versionen davor das auch schon gab.

Erwin hat geschrieben:Wie sieht es eigentlich mit der Zukunft von 2.5 aus?
Wird es dies dann irgendwann nicht mehr geben?
Oder wird es auch weiterhin zur Verfügung stehen und problemlos auf derzeitige BS und auch auf neuere BS installiert werden können?.

Python 2.5 wird es solange geben, solange es die Daten noch gibt, es wird nicht irgendwann mal global implodieren und verschwinden. Die Tarballs von 2.5 wirst du auch sicherlich noch auf zukünftigen Unices kompilieren und nutzen können, die Windows-Versionen werden vermutlich auch in zukünftigen Windows-Versionen laufen. Es wird eben das passieren was 2.3 passiert ist - es wurde von 2.4 ersetzt. 2.5 wird auch ersetzt werden - durch 2.6 und 3.0.

Tupel und Listen.
Hoffe mir passiert so schnell der Fehler nicht noch mal.
Ist ja nicht nur peinlich, sondern Jemand anders übernimmt dass dann vielleicht auch noch falsch.

Leonidas hat geschrieben: Es wird ein "What's New in Python 3.0" geben, so wie es für die Versionen davor das auch schon gab.

Also vermutlich auf Englisch?
Aber je länger ja Python gibt, desto mehr besteht wohl die Chance, dass es übersetzt wird?

Was weiß man eigentlich so vorab?
Gibt es, wenn man mit 2.5 weiter macht, vieles, was man beachten sollte, wenn man den gleichen Code dann für 3.0 verwenden will?

Leonidas hat geschrieben:Python 2.5 wird es solange geben, solange es die Daten noch gibt, es wird nicht irgendwann mal global implodieren und verschwinden. Die Tarballs von 2.5 wirst du auch sicherlich noch auf zukünftigen Unices kompilieren und nutzen können, die Windows-Versionen werden vermutlich auch in zukünftigen Windows-Versionen laufen. Es wird eben das passieren was 2.3 passiert ist - es wurde von 2.4 ersetzt. 2.5 wird auch ersetzt werden - durch 2.6 und 3.0.

Kompilieren?
Geht das auch für Linux? Also für Linux BS?

Insgesamt scheint mir, habe ich meine Frage nicht richtig gestellt.
Versuche ich es anders, zu mal Gewisse Dinge sich wohl scheinbar nicht vermeiden lassen.

Will mal versuchen, zu akzeptieren, dass ich halt auf 3.0 umsteigen muss:
Aber wie mache ich es, oder wie machen das dann Andere, die gerade an einem großen Projekt sind, und dies dann auf Python 3.0 umstellen wollen/müssen?
Gibt es dann Hilfswerkzeuge, die zum Beispiel aus "print 'var1'", dann "print('var1')" machen?

Und wie kommt Ihr vor allem damit zurecht?

Weil für mich ist das nicht nur frustrierend, sondern wenn ich etwas gemachtes wieder machen muss (print-Zeilen neu schreiben) dann ist das für mich ein Rückschritt. Ein Gefühl von, ich komme nie weiter, alles Zeitvergeudung.

Erwin hat geschrieben:
Leonidas hat geschrieben: Es wird ein "What's New in Python 3.0" geben, so wie es für die Versionen davor das auch schon gab.
Also vermutlich auf Englisch?
Aber je länger ja Python gibt, desto mehr besteht wohl die Chance, dass es übersetzt wird?

Die Möglichkeit besteht, aber die vorhergehenden "What's New"-Dokumente waren auch auf Englisch idR leicht zu verstehen. Nur ihre Fülle war ein Problem.

Erwin hat geschrieben:Was weiß man eigentlich so vorab?

Alles was in den PEPs 3000 und folgenden steht.

Erwin hat geschrieben:Gibt es, wenn man mit 2.5 weiter macht, vieles, was man beachten sollte, wenn man den gleichen Code dann für 3.0 verwenden will?

Ja, man sollte beachten, dass man nicht versuchen sollte Code sowohl für 3.0 als auch 2.x zu schreiben.

Erwin hat geschrieben:Kompilieren?
Geht das auch für Linux? Also für Linux BS?

Natürlich. Ich habe mir mein Python auf Gentoo Linux selbst kompiliert, das ist alles überhaupt kein Problem.

Erwin hat geschrieben:Will mal versuchen, zu akzeptieren, dass ich halt auf 3.0 umsteigen muss:
Aber wie mache ich es, oder wie machen das dann Andere, die gerade an einem großen Projekt sind, und dies dann auf Python 3.0 umstellen wollen/müssen?
Gibt es dann Hilfswerkzeuge, die zum Beispiel aus "print 'var1'", dann "print('var1')" machen?

Ja, der Konverter heißt 2to3.

Erwin hat geschrieben:Und wie kommt Ihr vor allem damit zurecht?

Ganz einfach. Code in 2to3 füttern, ggf. Probleme von Hand ausbessern - fertig. Sich über saubereren Code freuen.

Erwin hat geschrieben:Weil für mich ist das nicht nur frustrierend, sondern wenn ich etwas gemachtes wieder machen muss (print-Zeilen neu schreiben) dann ist das für mich ein Rückschritt. Ein Gefühl von, ich komme nie weiter, alles Zeitvergeudung.

Du darfst auch gerne noch jahrelang 2.x nutzen, 3.x wird sich sowieso nicht sonderlich schnell durchsetzen.

Achja, warum guckst du dir nicht Guidos Python 3.0-Talk auf Google Video an? Er erklärt da eine ganze Menge Sachen dazu.

Leonidas hat geschrieben: Die Möglichkeit besteht, aber die vorhergehenden "What's New"-Dokumente waren auch auf Englisch idR leicht zu verstehen. Nur ihre Fülle war ein Problem.

Bei meinem Englisch müsste ich im Vorfeld verdammt viel von der Materie verstehen, um zumindest den Großteil der Wörter und/oder Satz-Stellung richtig zu verstehen.
Deutsch wäre von daher viel hilfreicher für mich.

Leonidas hat geschrieben:
Erwin hat geschrieben:Gibt es, wenn man mit 2.5 weiter macht, vieles, was man beachten sollte, wenn man den gleichen Code dann für 3.0 verwenden will?
Ja, man sollte beachten, dass man nicht versuchen sollte Code sowohl für 3.0 als auch 2.x zu schreiben.

Wollte eigentlich gezielt wissen, welche Wörter man vorerst besser meidet. Wie print z.B..
Allerdings jetzt wo ich von dem 2to3 weiß, scheint mir es einfacher zu sein, den 2to3 dann drüber laufen zu lassen.
Womit sich die Frage erledigt/beantwortet haben sollte.
Danke.

Leonidas hat geschrieben:Natürlich. Ich habe mir mein Python auf Gentoo Linux selbst kompiliert, das ist alles überhaupt kein Problem.

Was für ein Tool hast Du hergenommen?
Ich benutzte als Linux-Distri Ubuntu (Gnome-Destop).
Würde da vermutlich das gleiche Tool laufen?

Leonidas hat geschrieben:Ja, der Konverter heißt 2to3.

Mal sehen, ob ich den finde. Danke.
Heißt der nur 2to3? Kein Py davor, oder ähnliches?

Leonidas hat geschrieben: Du darfst auch gerne noch jahrelang 2.x nutzen, 3.x wird sich sowieso nicht sonderlich schnell durchsetzen.

Aber eines Tage vermutlich schon?
Ich meine, wenn man noch etwas am Anfang steht, ist es doch wohl besser, gleich mit 3 weiter zu machen, oder?
Anderseits ... wen man die neue Funktionen nicht braucht, dann kann man ja jederzeit mit 2to3 ja alles auf 3 umschreiben lassen?
Ich darf nicht so viel darüber nachgrübeln.

Leonidas hat geschrieben:Achja, warum guckst du dir nicht Guidos Python 3.0-Talk auf Google Video an? Er erklärt da eine ganze Menge Sachen dazu.

Dürfte in Englisch sein, oder?
Meine Schwerhörigkeit machte es mir schwer die Muttersprache, also Deutsch, richtig zu lernen. Von Englisch dann ganz schweigen. Und wen das Englisch dann auch noch in Ton ist ... das wird dann nichts. Leider.

Vorweg: Ich habe mir diesen ganzen Thread nicht auf den allerletzten Satz durchgelesen, aber das meiste habe ich mitbekommen.

Zunächst möchte ich mal auf ein Vortrag von Guido van Rossum verweisen, der die Änderungen von Python 3000 behandelt. Dieser Vortrag ist schon relativ alt, fasst aber einige Punkte gut zusammen. Hier der Link: Youtube-Video. (EDIT: der Vorposter hat schon darauf verwiesen, hier einfach noch der Link zum anklicken

)

Betreffend des print-Statements (bzw. der print-Funktion) wird begründet, dass eine Migration zu einem Logging-Framework mit print als Funktion einfacher ist. Der Grund ist einfach, wenn ich print() durch einen Funktions-/Methodenaufruf ersetzen möchte, kann ich einfach "print" in "foo" oder "foo.bar" umbenennen. Ist print jedoch ein Statement, muss ich noch Klammern rund herum beifügen. Dies ist etwas aufwändiger und fehleranfälliger (ich sehe nicht wirklich grosse Probleme, weiss jedoch auch nicht, wie kompliziert man ein print-Statement maximal formulieren kann). Aber ich bin auch ein Befürworter der print-Funktion!

@ paedubucher

print habe ich jetzt als Beispiel hergenommen.

Was mich halt zu schaffen macht, sind Umstellungen.
Erst recht, wenn Sie für einen Laien keinen Sinn macht.
foo? foo.bar?
Sagt mir z. B. gar nichts. Also ist für mich die Umstellung derzeit ohne Sinn.
Bedeutet für mich nur Stress, weil ich etwas umlernen, nicht neu, sondern umlernen muss.

Erwin hat geschrieben:
Leonidas hat geschrieben:Ja, der Konverter heißt 2to3.
Mal sehen, ob ich den finde. Danke.
Heißt der nur 2to3? Kein Py davor, oder ähnliches?

Den gibts hier: http://svn.python.org/view/sandbox/trunk/2to3/

Gruß, Craven

Erwin hat geschrieben:
Leonidas hat geschrieben: Die Möglichkeit besteht, aber die vorhergehenden "What's New"-Dokumente waren auch auf Englisch idR leicht zu verstehen. Nur ihre Fülle war ein Problem.
Bei meinem Englisch müsste ich im Vorfeld verdammt viel von der Materie verstehen, um zumindest den Großteil der Wörter und/oder Satz-Stellung richtig zu verstehen.
Deutsch wäre von daher viel hilfreicher für mich.

Deutsche übersetzungen haben teilweise auch einfach das Problem, dass die Fachbegriffe schwer zu übersetzen sind. In einer Diskussion zu dem Thema sind wir auf ZF-Notation für List Comprehensions gekommen - definitiv nicht optimal.

Erwin hat geschrieben:Wollte eigentlich gezielt wissen, welche Wörter man vorerst besser meidet. Wie print z.B..

Du solltest nicht ``print`` meiden. 2to3 ist genug gut, um die meisten Einsätze von ``print`` korrekt zu übersetzen.

Erwin hat geschrieben:
Leonidas hat geschrieben:Natürlich. Ich habe mir mein Python auf Gentoo Linux selbst kompiliert, das ist alles überhaupt kein Problem.
Was für ein Tool hast Du hergenommen?
Ich benutzte als Linux-Distri Ubuntu (Gnome-Destop).
Würde da vermutlich das gleiche Tool laufen?

Ich nutze Portage, das ist das Paketmanagementsystem von Gentoo. Das läuft nicht unter Ubuntu (habe ich mal versucht). Aber Pakete selbstkompilieren kannst du auch "per Hand". Python 3.0a2 habe ich mit ``./configure --prefix=$HOME/python3 && make && make install`` kompiliert, war gar kein Problem.

Erwin hat geschrieben:
Leonidas hat geschrieben:Ja, der Konverter heißt 2to3.
Mal sehen, ob ich den finde. Danke.
Heißt der nur 2to3? Kein Py davor, oder ähnliches?

Nur 2to3.

Zu ``print``: Was ``print`` bringt - Einheitlichkeit.

Erwin hat geschrieben:Meine Schwerhörigkeit machte es mir schwer die Muttersprache, also Deutsch, richtig zu lernen.

Da haben wir was gemeinsam.

Mir macht allerdings das verfolgen deutschsprachiger Videos bereits Probleme.

Gruß Andy

Danke Euch Beiden (Craven und Leonidas) für den Link.

Dies läuft also unter Python 3?
Nun ja, sollte man eigentlich dann sowieso haben, wenn man den Code umschreiben lassen will auf 3.0.

Leonidas hat geschrieben: Deutsche übersetzungen haben teilweise auch einfach das Problem, dass die Fachbegriffe schwer zu übersetzen sind. In einer Diskussion zu dem Thema sind wir auf ZF-Notation für List Comprehensions gekommen - definitiv nicht optimal.

Es tun sich also auch die Übersetzer schwer?
Dann werde ich mich erst recht schwer tun.
Das kann ja heiter werden ... .
Aber es erklärt so manches ... .

Leonidas hat geschrieben:Ich nutze Portage, das ist das Paketmanagementsystem von Gentoo. Das läuft nicht unter Ubuntu (habe ich mal versucht). Aber Pakete selbstkompilieren kannst du auch "per Hand". Python 3.0a2 habe ich mit ``./configure --prefix=$HOME/python3 && make && make install`` kompiliert, war gar kein Problem.

Ok, notiert. Danke.
Verwirrt mich aber etwas.
Wenn man es in exe Kompilieren lassen will, braucht man ein extra Programm.
Ist das bei bzw. für Linux anders? ich meine, kann Linux etwa einfacher, vor allem dann wenn Python drauf ist, den Code in Linux-Pakete umwandeln?
Das wäre natürlich einerseits praktisch.
Anderseits muss ich mich dann bestimmt noch durch viel Materie durcharbeiten, um das zu verstehen/anwenden zu können.

Python 3.0 gibt es ja schon.
Ist das stable?
Habe was von alpha gelesen. Aber alpha, beta ... da weiß ich ja gar nicht mehr, welches unfertig ist. Oder sind es beide?

Erwin hat geschrieben:@ paedubucher

print habe ich jetzt als Beispiel hergenommen.

dito

Erwin hat geschrieben: foo? foo.bar?
Sagt mir z. B. gar nichts.

Mein Beispiel soll sagen, das du eine print-Funktion (mit Klammern) einfacher zu anderen Methodenaufrufen umkonvertieren kannst als ein print-Statement. foo ist eine Funktion, foo.bar soll die Methode "bar" in der Klasse "foo" benennen:

Code: Alles auswählen

print('Logging mit print()')
foo('Logging mit der Funktion \'foo\'')
foo.bar('Logging mit dem foo-Framework')

OK, ich benutze fortan "spam" statt "foo" und "eggs" statt "bar"

Erwin hat geschrieben:Danke Euch Beiden (Craven und Leonidas) für den Link.

Dies läuft also unter Python 3?

Nein, 2to3 läuft soweit ich weiß unter 2.x.

Erwin hat geschrieben:
Leonidas hat geschrieben:Ich nutze Portage, das ist das Paketmanagementsystem von Gentoo. Das läuft nicht unter Ubuntu (habe ich mal versucht). Aber Pakete selbstkompilieren kannst du auch "per Hand". Python 3.0a2 habe ich mit ``./configure --prefix=$HOME/python3 && make && make install`` kompiliert, war gar kein Problem.
Ok, notiert. Danke.
Verwirrt mich aber etwas.
Wenn man es in exe Kompilieren lassen will, braucht man ein extra Programm.
Ist das bei bzw. für Linux anders? ich meine, kann Linux etwa einfacher, vor allem dann wenn Python drauf ist, den Code in Linux-Pakete umwandeln?
Das wäre natürlich einerseits praktisch.
Anderseits muss ich mich dann bestimmt noch durch viel Materie durcharbeiten, um das zu verstehen/anwenden zu können.

Wir sprechen hier von zwei verschiedenen Sachen. Um Python zu kompilieren braucht man einen C-Compiler, wie GCC. Um Python-Programme zu kompilieren braucht man (streng genommen) nur den Python-Interpreter. Um Python-Programme auszuliefern braucht man keine kompilierten Versionen. Was man machen kann, ist es DEBs oder RPMs zu bauen. Wie das geht, steht in der RPM-Hilfe und im Maint-Guide von Debian. Um Python-Module zu verteilen gibt es noch eine weitere Möglichkeit: distutils und setuptools. Die setuptools ermöglichen es, Module mit einem einzigen Befehl herunterzuladen, zu kompilieren (wenn nötig) und zu installieren. Aber das ist alles ein anderes Thema. Wenn du fragen hast, öffne bitte einen neuen Thread.

Erwin hat geschrieben:Python 3.0 gibt es ja schon.
Ist das stable?
Habe was von alpha gelesen. Aber alpha, beta ... da weiß ich ja gar nicht mehr, welches unfertig ist. Oder sind es beide?

Nein, es ist nicht Stable. Die Reihenfolge ist Alpha - Beta - Final. Also zur Final-Version ist es noch etwas hin.

@ paedubucher

Du meinst halt das print als Funktion zu nutzen?
Nur ich habe bis jetzt eben keine Verwendung dafür, um es als Funktion nützen zu müssen.
Sehe da keinen Sinn.
Zumindest noch nicht.

Leonidas hat geschrieben:
Erwin hat geschrieben:Python 3.0 gibt es ja schon.
Ist das stable?
Habe was von alpha gelesen. Aber alpha, beta ... da weiß ich ja gar nicht mehr, welches unfertig ist. Oder sind es beide?
Nein, es ist nicht Stable. Die Reihenfolge ist Alpha - Beta - Final. Also zur Final-Version ist es noch etwas hin.

Und Alpha, die jetzige Version (?) hat bestimmt noch Mängel, oder?
Ich hoffe mal, dass es nicht all zu viele Veränderungen geben wird, und mir eine spätere Umstellung nicht all zu schwer fällt und kaum Ärger bereiten wird.

Statt ``make install`` sollte man besser ``make altinstall`` verwenden, sonst überschreibt man sich am Ende die bereits bestehende Python-Installation.

@Erwin: Traditionell bedeutet "alpha" in Entwicklung, nur für Entwickler innerhalb der Firma zum testen, und "beta" besondere, ausgewählte Kunden bekommen die Software zum Testen und Fehler melden. Bei Open Source gibt's ja in der Regel weder "firmenintern" noch Kunden im klassischen Sinn. Da muss der Anwender selber entscheiden was er mit "alpha" und "beta"-Software anfängt. Bei "alpha" muss man mit Fehlern rechnen, die den Entwicklern schon bekannt sind und das die Software noch nicht komplett fertig ist. Bei "beta" sollte die Software schon fertig sein und wenn man Fehler findet, kennen die Entwickler die in der Regel selbst noch nicht. Es sei denn ein anderer Betatester hat sie schon gemeldet.

*Du* solltest die "alpha" wohl nicht verwenden. Das ist wirklich eher für Leute die aus neugier mal reinschauen wollen, Fehler melden wollen, und/oder noch über Details mit den Entwicklern diskutieren wollen. Alles auf Englisch natürlich.

Fehler sind auf jeden Fall noch enthalten.

Einerseits kommt man auf lange Sicht bei Computern und Programmiersprachen nicht um Veränderungen herum. Wenn ich an die ganzen Zeilen Assembler auf dem C64 denke…

Andererseits wird die Python 2.x-Reihe eine ganze Weile parallel zu Python 3.x existieren und gepflegt und man kann Python 2.x auch danach noch selbst kompilieren.

Warte einfach noch ein wenig ab. Die Python-Entwickler wollen möglichst viele Neuerungen von 3.0 schon in 2.6 integrieren, also möglichst alles was keine Probleme bei der Rückwärtskompatibilität bringt. Damit wird der Sprung von 2.x nach 3.0 schonmal nicht mehr ganz so weit wie's momentan aussieht. Bevor die 2.6 sich nicht halbwegs durchgesetzt hat, fange ich jedenfalls nicht mit dem Portieren von vorhandenem Quelltext an.

Halte Dich am besten an Deine Linux-Distribution. Und denk immer dran, dass man Python-Versionen parallel installieren kann.

BlackJack hat geschrieben:Statt ``make install`` sollte man besser ``make altinstall`` verwenden, sonst überschreibt man sich am Ende die bereits bestehende Python-Installation.

Daher habe ich bei ``./configure`` ja auch ein Prefix angegeben. Es gab sogar irgendwo ein Linux, welches wie Windows alles in eigene Programmordner installiert hat. Mir fällt der Name aber nicht mehr ein.

Leonidas hat geschrieben:
BlackJack hat geschrieben:Statt ``make install`` sollte man besser ``make altinstall`` verwenden, sonst überschreibt man sich am Ende die bereits bestehende Python-Installation.
Daher habe ich bei ``./configure`` ja auch ein Prefix angegeben. Es gab sogar irgendwo ein Linux, welches wie Windows alles in eigene Programmordner installiert hat. Mir fällt der Name aber nicht mehr ein.

GoboLinux oO?

BlackJack hat geschrieben: Einerseits kommt man auf lange Sicht bei Computern und Programmiersprachen nicht um Veränderungen herum. Wenn ich an die ganzen Zeilen Assembler auf dem C64 denke…

Also ich lernte damals in der Schule Informatik auf einen C64.
Die Sprache war aber Basic. *g*

Wenn ich an GFA-Basic denke ... .
Damals, am Atari ST, hatte ich mich gegen GFA-Basic für Omikron-Basic entschieden.
Und das deshalb, weil mir Omikron vertrauter vor kam. Eben mit Nummerirung und so.
Ich hätte GFA nehmen sollen. Das war laut meiner Erinnerung an dessen Beschreibung ein Vorläufer oder sogar bereits eine Objektorientierte Programmiersprache.

Fehlende deutsche Dokumentation, in der ich die Gründe so wie auch die weiter laufende Ziele, nachvollziehen könnte, scheint es wohl leider auch nicht zu geben.
Das würde aber vermutlich zu mehr Akzeptanz führen, dass ich später umlernen muss, obwohl ich die Sprache derzeit als verdammt gut empfinde.

GFA-Basic würde ich definitiv nicht als objektorientiert bezeichnen. Die erste Mainstream-Sprache, der ich dieses Attribut geben würde war TurboPascal 5.5, und das kam später. Tatsächlich war GFA-Basic eher ein Pascal-Dialekt denn ein klassisches Basic - und der Grund, warum ich mir damals einen Atari kaufte... ;)

Stefan

PS: Signum war natürlich auch cool...

sma hat geschrieben:GFA-Basic würde ich definitiv nicht als objektorientiert bezeichnen. Die erste Mainstream-Sprache, der ich dieses Attribut geben würde war TurboPascal 5.5, und das kam später. Tatsächlich war GFA-Basic eher ein Pascal-Dialekt denn ein klassisches Basic - und der Grund, warum ich mir damals einen Atari kaufte...

Und bei mir war es umgekehrt:
Weil das fehlen von Zeilen-Zahlen, Goto per Name (?) und noch irgendwas mich gar nicht an Basic erinnerte, nahm ich dann Omikron.
Denn das neu lernen, nach dem ich schon etwas Basic konnte, wollte mir halt gar nicht gefallen.

BlackVivi hat geschrieben:GoboLinux oO?

Bingo, das wars. Lustige Sache eigentlich. Man wünscht sich fast noch /A, /C, /D etc

Erwin hat geschrieben:Fehlende deutsche Dokumentation, in der ich die Gründe so wie auch die weiter laufende Ziele, nachvollziehen könnte, scheint es wohl leider auch nicht zu geben.
Das würde aber vermutlich zu mehr Akzeptanz führen, dass ich später umlernen muss, obwohl ich die Sprache derzeit als verdammt gut empfinde.

Sprichst du nun von Basic oder Python? Der Kontext sagt Basic, die Logik sagt Python.

Und wenn Python, dann stimmt die Logik nicht einmal. Es gibt nämlich ausgiebig Dokumentation auf Deutsch für Python einschließlich eines Buches, was in der Letzten Zeit aggressiv überall beworben und es nicht besser macht (BlackVivi, danke für die kritische Bemerkung auf Pro-Linux *g*). Aber es gibt auch gute Deutschsprachige Lektüre. Und Python 3.0 wird gar nicht so viel umlernen sein, es wird eher wie ein Schritt von 2.4 auf 2.5 sein, nur dass da Sachen dabei sein werden, die alten Quellcode nicht mehr vorwährtskompatibel lassen. Aber alles in allem wird Python 3.0 eben hauptsächlich ein saubereres, vereinfachtes Python 2.x. Einige hätten sich da mehr erwartet.

Das deutsche Python-Forum

Python wird immer komplizierter

Keynote