Ist Python 3 ausgereift?

[friedduck]

Hallo Leute,

ich fange grad frisch mit Python an und habe mich gleich für die aktuellere
3er Version entschieden, war das ein Fehler?

Weil so wie ich leider feststellen muss funktionieren viele Erweiterungen nicht mit Python 3.
Ein Beispiel ist Reportlab, läuft höhsten unter Python 2.7.

Vieles muss selber kompilliert werden, ich finde das als Python Einsteiger echt zum k#####.

Die Frage ist, soll ich Python 3 einstampfen und auf 2.7 umschwenken?

[sma]

Python 3 ist ausgereift. Aber da "gut genug" der Feind des besseren ist, haben viele Anbieter von Modulen keine Lust/Zeit/Antrieb, diese zusätzlich auch für Python 3 anzubieten. Python 2.x machen sie alle. Daher musst du vorher immer gucken, ob das, was du machen willst, weitere Module benötigt und ob diese für Python 3 verfügbar sind.

Wenn du dazu keine Lust hast, nimm Python 2.7. Der Unterschied ist sehr gering. Bei Python 2.7 musst du daran denken, dass "str" nicht mehr für "richtige" Strings steht, sondern für Byte-Strings und du für Strings, die alle Zeichen aus dem Unicode-Zeichensatz enthalten können sollen, ein "u" vor einem String angeben musst. Ansonsten ist "print" keine Funktion, sondern noch eine Anweisung (was man aber mit "from __future__ import print_function" ändern kann) und noch ein paar Kleinigkeiten in der Syntax sind anders.

Stefan

[deets]

sma war schneller..

[friedduck]

Danke für die schnellen Antworten, Python 2 ist auch installiert + ein paar Module und alles ist ohne irgendwelche Fehlermeldungen durchgelaufen

Scheint wohl die richtige Entscheidung gewesen zu sein...

[noisefloor]

Hallo,

Python3 ist defintiv die zukunft. Gut, ich habe mich selber noch nicht ernsthaft damit beschäftigt, u.a. auch wegen ReportLab (oder mangels ReportLab für Python 3.x).

Da aber so nach und nach alle (z.B. die ganzen Linux Distros) auf Python 3 als Standard umstellen oder schon umgestellt haben, ist die Zeit absehbar, wann Python 2.x nur noch auf ein paar Produktiv Serverapplikationen läuft und alles andere Python 3 ist.

Gruß, noisefloor

[jens]

Beim Django Project arbeiten einige wohl auch wieder am Python 3 Port. Wenn ich das richtig gelesen habe, wollen die mit hilfe von six eine Codebasis haben die dann 2 und 3 gleichzeitig unterstützt. Ich denke das ist auch der beste Weg...

[Py-Prog]

Ich kapiers nicht viele steigen nicht auf Python 3 um weil's nicht alle Module etc. dafür gibt, aber wenn keiner umsteigt dann rentiert es nicht nicht die Module zu Portieren und es gibt auch weiter hin nicht alles für 3.x was es für 2.x gibt.

Das erinnert mich irgendwie an diesen Börsen Crash wo auch die Leute selber schuld waren das ihre Aktien wertlos wurden.

[Hyperion]

Ich kapiers nicht viele steigen nicht auf Python 3 um weil's nicht alle Module etc. dafür gibt, aber wenn keiner umsteigt dann rentiert es nicht nicht die Module zu Portieren und es gibt auch weiter hin nicht alles für 3.x was es für 2.x gibt.

Naja, sicherlich ist das irgend wo ein klassisches Henne-Ei-Problem. Andererseits war das ja durchaus "geplant" - so ein Umstieg findet ja nicht von heute auf morgen statt. Und im Moment passiert ja einiges, da nach Arch nun auch weitere Linux-Distros ihr Standard-Python auf Version 3 umstellen.

Und parallel kann man das ja auch schon seit längerem betreiben.

Das erinnert mich irgendwie an diesen Börsen Crash wo auch die Leute selber schuld waren das ihre Aktien wertlos wurden.

Na irgend wie sind es immer "Leute", die an etwas schuld sind Aber nur mal so aus Neugierde: Welchen meinst Du da genau?

[jens]

Dir Frage ist, ob man dadurch nicht folgern sollte, das es wenig Sinn macht "Große Umbrüche" vorzunehmen und sie besser in viele kleine unterteilen sollte...

Das Problem was ja auch irgendwie, das Python 3 zu 2 nicht so super viel zu bieten hat, das sich alle wie wild drauf gestürzt haben...

[Hyperion]

Das Problem was ja auch irgendwie, das Python 3 zu 2 nicht so super viel zu bieten hat, das sich alle wie wild drauf gestürzt haben...

Hm... sma ist ja auch ein Kritiker dieser Vorgehensweise. Ich bin da unentschlossen - alte Zöpfe lassen sich eben nicht immer sanft kappen. Und das alte System dann zu schnell sterben zu lassen ist dann auch nicht wirklich sinnvoll. Aber diese Diskussion ist ja nun schon so oft geführt worden...

[Py-Prog]

Na irgend wie sind es immer "Leute", die an etwas schuld sind Aber nur mal so aus Neugierde: Welchen meinst Du da genau?

Ich meine den da wo die Leute Angst hatten das die Aktien wertlos werden und dann alle verkauft hatten und dadurch verloren dann auch alle Aktien ihren wert. Wenn aber alle ihre Aktien Behalten hätten wäre gar nichts passiert ...

Wann das war weiß ich zwar nicht, aber es ist doch viel wichtiger das man weiß was passiert ist und warum und nicht wann.

[lunar]

@Hyperion: Also, manche entwickeln noch mit Visual C++ 6(!), und dabei hat C++/CLI demgegenüber eine Menge zu bieten, den VC++ ist richtig alt (locker zehn Jahre älter als Python 3) und richtig schlecht (MFC anyone?) Insofern glaube ich nicht, dass da irgendein Zusammenhang besteht zwischen Umfang der Änderungen und Annahme durch die Community…

[Hyperion]

@lunar: Naja, das sehe ich doch genauso

[bremer]

Python 3 ist ausgereift. Aber da "gut genug" der Feind des besseren ist, haben viele Anbieter von Modulen keine Lust/Zeit/Antrieb, diese zusätzlich auch für Python 3 anzubieten. Python 2.x machen sie alle. Daher musst du vorher immer gucken, ob das, was du machen willst, weitere Module benötigt und ob diese für Python 3 verfügbar sind.

Wenn du dazu keine Lust hast, nimm Python 2.7. Der Unterschied ist sehr gering. Bei Python 2.7 musst du daran denken, dass "str" nicht mehr für "richtige" Strings steht, sondern für Byte-Strings und du für Strings, die alle Zeichen aus dem Unicode-Zeichensatz enthalten können sollen, ein "u" vor einem String angeben musst. Ansonsten ist "print" keine Funktion, sondern noch eine Anweisung (was man aber mit "from __future__ import print_function" ändern kann) und noch ein paar Kleinigkeiten in der Syntax sind anders.

Stefan

Immer wenn ich externe Module nutzen will, sind sie nur für 2.x verfügbar. Von ausgereift kann also keine Rede sein. Ich finde man muss da schon die Sprache als ganzes mit all seinen Abhängigkeiten betrachten und nicht nur den Kern.

Python3 ist defintiv die zukunft. Gut, ich habe mich selber noch nicht ernsthaft damit beschäftigt, u.a. auch wegen ReportLab (oder mangels ReportLab für Python 3.x).

Python 3.x ist ganz sicher nicht die Zukunft.

Da aber so nach und nach alle (z.B. die ganzen Linux Distros) auf Python 3 als Standard umstellen oder schon umgestellt haben, ist die Zeit absehbar, wann Python 2.x nur noch auf ein paar Produktiv Serverapplikationen läuft und alles andere Python 3 ist.

An Hochschulen wurde in meinem Umfeld immer nur mit Python 2.x gearbeitet. Ich sehe eher eine permanente Spaltung. Auf der einen Seite Distros mit 3.x, auf der anderen Seite viele wichtige Module exklusiv für 2.x.



Kurzum die Entwickler und der Diktator sind ihren Pflichten nicht gerecht geworden. Man hatte keine Konzepte, es nicht zu einer Spaltung kommen zu lassen.

Und erzählt mir nicht, wer angeblich alles wieder an einem Port arbeitet, die Diskussion wird doch jedes Jahr geführt. Python 3k (lol 3k) war 2008! Das ist fast 4 Jahre her.

[Hyperion]

Immer wenn ich externe Module nutzen will, sind sie nur für 2.x verfügbar.

Kannst Du uns da mal Beispiele geben? Evtl. hast Du eben "Pech", dass Du in Bereichen arbeitest, für die Python3 eben noch nicht geeignet ist.

Von ausgereift kann also keine Rede sein. Ich finde man muss da schon die Sprache als ganzes mit all seinen Abhängigkeiten betrachten und nicht nur den Kern.

Öh... und wie kann man *externe* Entwickler zwingen, ihre Module gefälligst im Vorfeld auf eine neue Sprachversion zu portieren? Das kann ja nicht einmal Microsoft... und .NET ist ja nun auch schon >10 Jahre alt...

Python 3.x ist ganz sicher nicht die Zukunft.

Weil...?

Es wird ja kein Python 2.8 mehr geben - auf lange Sicht wird der 2er Zweig eben sterben. Natürlich kann das noch Jahre dauern - analog zu Linux. Den 2.4er Kernel nutzen sicherlich auch noch Leute. Die Mehrheit der Anwender dürfte mittlerweile doch schon bei 2.6 oder gar 3.x sein.

An Hochschulen wurde in meinem Umfeld immer nur mit Python 2.x gearbeitet.

Ah ja... *wurde* ist Dir selber schon aufgefallen? So eine Umstellung ist immer ein *Prozess*, kein Quantensprung

Ich sehe eher eine permanente Spaltung. Auf der einen Seite Distros mit 3.x, auf der anderen Seite viele wichtige Module exklusiv für 2.x.

Nö. Das ist eben der *Prozess*, eine Art "wechselseitiges Hochschaukeln". Je mehr Module für Python3 verfpgbar sind, desto mehr Entwickler werden umsteigen. Je mehr Distros Python3 per default nutzen, desto mehr sind die Entwickler von Modulen motiviert, ihre Software zu portieren. Da man problemlos beide Varianten parallel nutzen kann, sind doch viele Probleme gar nicht wirklich existent.

Kurzum die Entwickler und der Diktator sind ihren Pflichten nicht gerecht geworden. Man hatte keine Konzepte, es nicht zu einer Spaltung kommen zu lassen.

Zum einen kann imho nicht von Spaltung die Rede sein und zum anderen: Wie hättest Du das denn verhindert? Das würde mich doch mal brennend interessieren.

Und erzählt mir nicht, wer angeblich alles wieder an einem Port arbeitet, die Diskussion wird doch jedes Jahr geführt. Python 3k (lol 3k) war 2008! Das ist fast 4 Jahre her.

Ja und? Es gibt auch noch jede Menge C-Programme, die kein C99 unterstützen - das ist sogar 13 Jahre her! Wo ist das Problem? Selbst Java wird ja noch in 1.4 eingesetzt (VW anyone?) und da war der Sprung auf 1.5 (aka Java 5) Gold wert, vermutlich sogar mehr als bei Python2 auf 3. (Wobei dort imho der Fehler gemacht worden ist, die Versionen kompatibel zu halten... dadurch hat man sich die suboptimalen Generics eingehandelt...)

BTW: Weiß jemand, ob Microsoft die binäre Abwärtskompatibilität für ihre Genereics in .NET geopfert haben? Die kamen afair doch auch erst später dazu? Als Laie im Bereich Kompiler-KnowHow würde ich naiv annehmen, dass das anders gar nicht geht - aber vielleicht irre ich da ja auch.

[snafu]

Doch, Python 3 *ist* die Zukunft. Es ist gut, dass die Distris zunehmend den Schritt gehen, Fakten zu schaffen, indem allmählich nur noch Python 3 als Standard-Interpreter ausgeliefert wird. Nur so entsteht der nötige Druck auf die Entwickler, nicht bis in alle Ewigkeit für 2.7 zu entwickeln.

Klar, es sind keine bahnbrechenden Neuerungen, die bisher eingeführt wurden. Aber die Summe der Teile wächst ja stetig an. Inzwischen ist der neue Zweig immerhin so gut wie bei Version 3.3 angelangt (Blick in What's New gefällig?). Das kann man doch nicht einfach ignorieren. Mit der Einstellung hätte man auch ganz einfach bei 2.6 bleiben können.

Übrigens denke ich, das selbstauferlegte Moratorium hat auch seinen Teil zu der Denke beigetragen, dass Python 3.x ja eh nichts neues bringen würde. War vielleicht nicht das beste Timing, aber hinterher ist man immer schlauer.

[BlackJack]

@snafu: Ich kann mit Druck auf 3.x umzusteigen überhaupt nichts anfangen weil ich aufgrund fehlender Abhängigkeiten nicht umsteigen *kann*. Der Druck wäre bei mir an der völlig falschen Stelle ausgeübt und würde hier nur Leidensdruck erzeugen.

[lunar]

@bremer: Ich glaube nicht, dass Deine spezielle Situation für „Python als Ganzes“ steht, ebenso wie Hochschulen sicherlich nicht das Maß aller Dinge sind. Ist es schade, dass Du Python 3 nicht verwenden kannst, doch das ist eher Dein persönliches Problem, in anderen Bereich kann man Python 3 mittlerweile sehr gut verwenden. GvR und die Python-Entwickler sind auch in keiner Weise verpflichtet, Python 3 für Dich benutzbar zu machen.

Es ist irgendwo auch eine persönliche Entscheidung, ob man willens ist, sich auf Neues einzulassen, und darauf hinzuarbeiten, eine neue Version mit samt ihren neuen Features und Möglichkeiten – in Python 3.3 gibt es davon mittlerweile einige – verwenden zu können, selbst wenn man dafür einiges an Aufwand betreiben muss, oder ob man beim Altbekannten bleibt, und darüber klagt, dass man den Fortschritt nicht für lau bekommt…

@Hyperion: .NET-Bytecode ist nicht abwärtskompatibel, doch da mehrere Versionen parallel verwendet werden können, ist das kein Problem. Auf jedem über Windows-Update verwalteten System sind alle Versionen von 2 bis 4 installiert, und die Laufzeitumgebung sorgt dafür, dass ein Programm immer mit der Version ausgeführt wird, gegen die es kompiliert wurde (sofern das Programm in der Konfiguration nicht explizit Kompatibilität mit höheren Versionen angibt).

Zudem ist Bytecode in aller Regel aufwärtskompatibel, so dass man Bibliotheken, die gegen ältere .NET-Versionen kompiliert wurden, auch in einer neueren Laufzeitumgebung verwenden kann. Seit .NET 4 kann man ohnehin mehrere Versionen der Laufzeitumgebung im selben Prozess ausführen, so dass Kompatibilitätsprobleme eigentlich kaum noch auftreten.

Generics kann man allerdings – mit gewissen Abstrichen bei der Typsicherheit – auch ohne Änderungen des Bytecode-Formats implementieren, indem man sie in Casts kompiliert.

[bremer]

Immer wenn ich externe Module nutzen will, sind sie nur für 2.x verfügbar.

Kannst Du uns da mal Beispiele geben? Evtl. hast Du eben "Pech", dass Du in Bereichen arbeitest, für die Python3 eben noch nicht geeignet ist.

PIL and matplotlib. Abgesehen davon nocht wxPython, PyGTK, py2exe und Django. Django wird die Unterstützung für 2.5 aufgeben in der nächten größeren Version.

Das ist das Problem. Viele, wenn nicht die meisten Bibliotheken stürzen von der Klippe.

Von ausgereift kann also keine Rede sein. Ich finde man muss da schon die Sprache als ganzes mit all seinen Abhängigkeiten betrachten und nicht nur den Kern.

Öh... und wie kann man *externe* Entwickler zwingen, ihre Module gefälligst im Vorfeld auf eine neue Sprachversion zu portieren? Das kann ja nicht einmal Microsoft... und .NET ist ja nun auch schon >10 Jahre alt...

Da muss man kreativ sein.

Aber wenn man sich nicht darum bemüht, könnte man wenigstens die Werbung einstellen, wie z. B. "extensive standard libraries and third party modules for virtually every task".

An Hochschulen wurde in meinem Umfeld immer nur mit Python 2.x gearbeitet.

Ah ja... *wurde* ist Dir selber schon aufgefallen? So eine Umstellung ist immer ein *Prozess*, kein Quantensprung

2012.

Nö. Das ist eben der *Prozess*, eine Art "wechselseitiges Hochschaukeln". Je mehr Module für Python3 verfpgbar sind, desto mehr Entwickler werden umsteigen. Je mehr Distros Python3 per default nutzen, desto mehr sind die Entwickler von Modulen motiviert, ihre Software zu portieren. Da man problemlos beide Varianten parallel nutzen kann, sind doch viele Probleme gar nicht wirklich existent.

Die alte Leier.

Zum einen kann imho nicht von Spaltung die Rede sein und zum anderen: Wie hättest Du das denn verhindert? Das würde mich doch mal brennend interessieren.

Einen guten Übersetzer schreiben. Python 2.x wesentlich früher aufgeben. Warum wurde es denn noch parallel weiterentwickelt, wenn der Sprung kommen sollte?

@bremer: Ich glaube nicht, dass Deine spezielle Situation für „Python als Ganzes“ steht, ebenso wie Hochschulen sicherlich nicht das Maß aller Dinge sind. Ist es schade, dass Du Python 3 nicht verwenden kannst, doch das ist eher Dein persönliches Problem, in anderen Bereich kann man Python 3 mittlerweile sehr gut verwenden. GvR und die Python-Entwickler sind auch in keiner Weise verpflichtet, Python 3 für Dich benutzbar zu machen.

Es ist irgendwo auch eine persönliche Entscheidung, ob man willens ist, sich auf Neues einzulassen, und darauf hinzuarbeiten, eine neue Version mit samt ihren neuen Features und Möglichkeiten – in Python 3.3 gibt es davon mittlerweile einige – verwenden zu können, selbst wenn man dafür einiges an Aufwand betreiben muss, oder ob man beim Altbekannten bleibt, und darüber klagt, dass man den Fortschritt nicht für lau bekommt…

@Hyperion: .NET-Bytecode ist nicht abwärtskompatibel, doch da mehrere Versionen parallel verwendet werden können, ist das kein Problem. Auf jedem über Windows-Update verwalteten System sind alle Versionen von 2 bis 4 installiert, und die Laufzeitumgebung sorgt dafür, dass ein Programm immer mit der Version ausgeführt wird, gegen die es kompiliert wurde (sofern das Programm in der Konfiguration nicht explizit Kompatibilität mit höheren Versionen angibt).

Zudem ist Bytecode in aller Regel aufwärtskompatibel, so dass man Bibliotheken, die gegen ältere .NET-Versionen kompiliert wurden, auch in einer neueren Laufzeitumgebung verwenden kann. Seit .NET 4 kann man ohnehin mehrere Versionen der Laufzeitumgebung im selben Prozess ausführen, so dass Kompatibilitätsprobleme eigentlich kaum noch auftreten.

Generics kann man allerdings – mit gewissen Abstrichen bei der Typsicherheit – auch ohne Änderungen des Bytecode-Formats implementieren, indem man sie in Casts kompiliert.

Ich hab' kein Problem damit, mehrere Versionen zu nutzen (wobei das zumindest unter Windows manchmal Schwierigkeiten bereitet.) und ich finde 3.x oft schlüssiger.

Mehrere .NET-Versionen installieren zu müssen ist eine Notlösung und IMHO in der Tat ein Problem. Ich will garnicht wissen, welche Sicherheitsrisiken das birgt.

[lunar]

@bremer: PyGtk ist wie Gtk 2 selbst veraltet, und durch PyGObject ersetzt, welches Python 3 unterstützt. py2exe lässt sich durch cx_freeze ersetzen, welches ebenfalls Python 3 unterstützt. Um wxPython ist es nicht schade, denn wx ist veraltet. Darüber hinaus unterstützen PyQt, PyQwt, numpy, scipy und diverse andere Bibliotheken Python 3. Die Situation ist also weiß Gott nicht so dramatisch, wie Du sie darstellst.

Am Beispiel von Django lässt sich zeigen, warum vier Jahre ein kurzer Zeitraum für einen Portierung eines so umfangreichen Projekts ist, selbst wenn Dir dieser Zeitraum sehr lang erscheinen mag. Django hängt von diversen Bibliotheken und Schnittstellen ab, u.a. Datenbankanbindungen und WSGI. Von WSGI wiederum hängt auch jedes andere Webrahmenwerk ab. Django ist mithin gezwungen, seine Portierung mit diversen Bibliotheken und anderen Rahmenwerke zu koordinieren. Angesichts der Vielfalt des Python-Okösystems ist das in vier Jahren kaum zu schaffen.

Ich glaube, Du unterschätzt Aufwand und Komplexität einer solchen Portierung. Deine Forderung, Python 2 früher einzustellen, ist weltfremd. Soll den Bibliotheken noch weniger Zeit zur Portierung bleiben?! Dann gäbe es jetzt noch weniger Module für Python 3, wir wären aber alle dazu gezwungen, Python 3 zu verwenden, da Python 3 nicht mehr unterstützt werden würde… Du hättest dann noch mehr Grund zur Klage über fehlende Module.

Die Forderung, einen „guten Übersetzer“ zu schreiben, ist ein schlechter Witz. 2to3 existiert, doch Python-Quelltext zu transformieren, ist aufgrund der dynamischen Natur und der fehlenden Typinformationen alles andere als leicht, und in manchen Fällen sogar unmöglich.

Den Zusammenhang zwischen Sicherheitsrisiken und parallel installierten .NET-Versionen sehe ich nicht. Jede .NET-Version wird mit Sicherheitsaktualisierungen und Fehlerkorrekturen versorgt, .NET 2 ist mithin nicht unsicherer als .NET 4.