Das deutsche Python-Forum

Sprachtechnisch kann man mit Python wohl weniger machen, aber die Stdlib scheint mir doch etwas umfangreicher zu sein - das will auch alles beschrieben sein. Allerdings habe ich das Buch nicht, wenn ich mir das Inhaltsverzeichnis ansehe scheinen da aber auch ziemlich viele nicht wirklich interessante Themen zu sein. So sind die Kapitel über Tkinter arg lang, und Server Side Scripting sollte wohl aus dem Buch inzwischen entfernt werden.

Wahrscheinlich kommt eben so die große Seitenanzahl zusammen.

Thread mal wieder herauf holt.
Muss ja nicht für alles ein neuer aufgemacht werden.

Mir geht es hier in dem Fall um print, da dies unter anderem auch angesprochen wurde.

Wenn ich das richtig verstanden haben, wird print also eine Funktion und kann somit mit:

Code: Alles auswählen

print('variable')

Texte ausgeben?
Was derzeit übrigens auch geht, bzw. sind das dann Listings.
Und genau an dem Punkt komme ich jetzt total durcheinander.
Wenn man

Code: Alles auswählen

print('var1','var2','var3')

eingibt, gibt er ja eine Listing von "('var1','var2','var3')" aus.
Anders als wenn man

Code: Alles auswählen

print 'var1','var2','var3'

schreibt.
Da spuckt er jedes einzeln aus, also ohne Klammern = "var1,var2,var3".

Wie funktioniert dann mit dem neuen print als Funktion dann noch das Listing??

Was Du das als "Listing" bezeichnest heisst Tupel. Und Deine Ausgabe für das 2.5er ``print`` ohne Klammern dürfte keine Kommata enthalten.

Ich weiss jetzt ehrlich gesagt nicht so ganz was Du wissen willst. Wenn Du in Python 3.x ein Tupel ausgeben willst, dann musst Du das genau wie in 2.5 einfach angeben.

In 3.0:

Code: Alles auswählen

>>> print('var1', 'var2', 'var3')
var1 var2 var3
>>> print(('var1', 'var2', 'var3'))
('var1', 'var2', 'var3')

In 2.5:

Code: Alles auswählen

In [27]: print 'var1', 'var2', 'var3'
var1 var2 var3

In [28]: print ('var1', 'var2', 'var3')
('var1', 'var2', 'var3')

Da ist abgesehen von einem Klammerpaar kein Unterschied zwischen den beiden Versionen.

Hi Erwin!

Ich vermute du fragst dich, was genau passiert wenn man sowas hier macht (Python 2.5):

Code: Alles auswählen

print arg1, arg2, arg3

Das ist ganz einfach. Die Print-Anweisung gibt nacheinander jedes arg aus, indem es die stringrepresentation (arg.__repr__) des Objektes zurueckgibt. Die Anweisung ist also das gleiche wie zB:

Code: Alles auswählen

print arg1,
print arg2,
print arg3

Das Komma hat in dem Fall den Effekt, dass kein Zeilenumbruch angehaengt wird, nachdem arg ausgegeben wurde.

Solange du Rueckgabewerte hast, kannst du so alles moegliche ausgeben, (fast) ohne auf den Objekttyp achten zu muesen (immernoch Python 2.5):

Code: Alles auswählen

def rueckgabefunktion():
    return "bla", "blub"

print 5, "5", (5,5), [5,5], {"5": 5}, True, False, None, rueckgabefunktion

Ausgabe:

Code: Alles auswählen

5 5 (5, 5) [5, 5] {'5': 5} True False None ('bla', 'blub')

Tulpel, stimmt.
Bringe die Beiden immer durcheinander.

Stimmt ja.

Einfach noch mal Klammern machen.
War wohl derzeit total durcheinander.
Hatte es Heute einfach mal getestet, ob es nicht schon bei 2.5 geht, da kam bei

Code: Alles auswählen

print 'var1'
print('var1')

Beiden das gleiche raus.
Dachte deshalb, dass es bereits mit 2.5 möglich ist.
Inzwischen fiel mir aber ein, dass keins von den Beiden ein Tulpel ist, weil ja ein Komma fehlt:

Code: Alles auswählen

print('var1',)

Hat mich alles leider durcheinander gebracht.
Sorry.

Ob man vielleicht eine Zusammenfassung erstellen kann, über die Veränderungen?
Und zwar im Positiven Sinne.
Wo man also vor allem die Vorteile hervorhebt?
Wäre für mich, der etwas gegen ständigem Wechsel (von einer Version zur nächsten ... ) was hat, sehr hilfreich.
Oder gibt es schon so was auf Deutsch?

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?

edit:
@ nkoehring

Nun, diese Frage stellte sich indirekt zugleich mit der Frage, wie man Tulpel macht, oder umgekehrt (nicht macht).
Bzw. wie print dann auseinander halten soll, was Tulpel ist, und was jeweils einzeln ausgeben werden soll.
Aber das man dann für Tulpel zusätzlich noch mal eine Klammer macht, wäre eigentlich ja das naheligenste gewesen.

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.

Das deutsche Python-Forum

Python wird immer komplizierter

Keynote