"Die PyPy-Variante für Python 3 machte offenbar keine Fortschritte, " Beim 3er Monty solls ja auch so sein, daß viele nicht vom 2er aufs 3er umsteigen, weils nicht lohnt und frameworks etc n icht unterstuetzt werden und so komplett.
Wär doof, wenn Python den Javaweg geht. Ewig Potential, aber dann, naja, gruetze werden. Nix gegen java, aber ich find python besser oder eher schoener, Qualitaet kann ich nicht wirklich beurteilen.
Dem kann ich mich nur anschließen. Man mag zu Canonical stehen wie man will, aber mit der konsequente Umstellung auf Python 3.4 haben sie der Community viel Arbeit abgenommen.
Also ich nutze bei neuen Projekten nur mehr Python 3. Hauptgrund dafür sind die Encodingprobleme in Python 2. Was ich in Python 2 dafür schon Zeit verschwendet habe... Außerdem gibt es mittlerweile alle Module, die ich brauche auch schon für Python 3.
Python3 "versteckt" vieles besser vor dem Benutzer, ähnlich wie Java oder andere Sprachen es machen, da es auf das System weite Default Encoding bei allen IO-Operationen setzt.
Dies ist imho leider eine schlechte Entscheidung, weil sie die Portabilität von Code erschwert. Solange man nur auf seinem System arbeitet (ergo für sich entwickelt), wird man unter Linux aktuell kaum Probleme spüren, sofern utf-8 als Default Encoding eingestellt ist.
Naja, das bessere String-Konzept hat schon Python 3 - von "Encoding-Problemen" befreit das aber gar nicht, schließlich müssen die Bytes ja irgend wie in einen (Unicode-)String reinkommen.
Zu Python 2 ist ein Entwickler eben früh darauf aufmerksam geworden, nun wird er es erst spät.
Ich wäre für UTF-8 als Default-Encoding gewesen. Damit hätte man eine fixe Konvention gehabt und alles wäre gut.
Hat man das Unicode-Prinzip von Python 2.x erst einmal verstanden, ist es eigentlich sehr sinnvoll, die klare Trennung der beiden Stringtypen ist leicht zu durchschauen.
Das einzige Problem von Python 2.x sind die mitgelieferten Libs, welche Teils zickig auf Unicode-String reagieren. Für einige hat man Workarounds geliefert (codecs), was man sicher hätte auch anders lösen können. Eigentlich wäre ein Ändern des Stringsystems gar nicht nötig gewesen, man hätte eben nur die Libs aufräumen und korrigieren müssen, dann wäre es für die meisten User schon optimal gewesen. Einige Anpassungen, wie das Ändern von "print" waren IMHO unnötig, wenn auch nicht dramatisch.
Zu Anfang war ich Python 3.x noch deutlich positiver eingestellt, vor allem aber weil ich das Unicode-Modell von Python 2.x nicht verstand. Als mir klar wurde, das meine Probleme eher die Schuld der Libs, als denn von Python selbst waren, änderte sich meine Meinung jedoch.
Definiert man beim laden von Daten, sowie bei der Ausgabe, sauber die Encodierung, kann ich keine Probleme mit Python 2.x feststellen. Meine Anwendungen nutzen schon heute nur Unicode, trotzt Python 2.x, und es läuft damit sehr gut. Auch ist der Quellcode dadurch kein Stück größer, als er es mit Python 3.x wäre.
Das dürfte auch das wesentliche Problem von Python 3.x sein: Erfahrene Entwickler brauchen es nicht, stören sich aber am Wechsel, der ihnen einen nutzlosen Aufwand bringt. Diese wiederum raten unerfahrenen Entwickler aber von Python 3.x ab, da sich die Masse der Entwickler eben bei 2.x befindet.
Zumal ich nicht davon überzeugt bin, das Python 3.x am Ende wirklich besser ist. Python 2.x zwingt einen Entwickler oftmals dazu klar zu definieren, um welches Encoding es sich handelt, außer es spielt keine Rolle (z.B. weil es nie ausgegeben wird). Dies klare Linie macht es am Ende einfach sauberen Code zu schreiben, da eigentlich alles von außen erstmal undefiniert ist. Python 3.x geht aber von einer Unicode Welt aus, die es allerdings gar nicht gibt unter Linux. Hier kann und wird oftmals ein Mix vorliegen, womit man dann eher in Probleme läuft. Doch da Python in 90% der Fälle recht hat, wägt man sich in einer Sicherheit, die es nicht gibt. Am Ende muss man Python 3.x genauso auf die Details hinweisen, nur ist es doch aktuell weniger klar beschrieben, und es gibt neue und wenig bekannte Stolperfallen.
Ein paar nette Zeilen dazu von Armin Ronacher finden sich in dessen Blog: http://lucumr.pocoo.org/
Meine Erfahrungen mit Python 3.x sehen dann auch so aus: In einer reinen Unicode-Welt ist es einfacher damit zu arbeiten, in einer Mixed-Welt hingegen eher sogar schwerer. Da die Realität jedoch oftmals eher ein Mix ist, macht es Python 3.x sogar aufwendiger, sauberen Code zu schreiben.
Ich schreib nur noch Hybride weshalb ich das Konzept von Python 2 recht einleuchtend finde. Wie du schon erwähnt hast, gibts einige Standardbibliotheken die gar nicht mit Unicode können. Und da wir in keiner perfekten Welt leben und mir so vorkommt das latin genauso häufig anzutreffen ist wie utf-8, kommt man bei Python3 auch nicht um das Problem von Encoding herum. Generell bin ich mehr ein Freund von explizit angeben, statt sich auf dem Default zu verlassen. Letzteres hat dazu geführt, dass bereits in der 2er Linie viel Code gibt, der nicht mehr korrekt funktioniert weil man open als Standard Text statt Binär öffnet.
Da ich leider unter und für Windows entwickeln muss ist für mich Python 3 die bessere Wahl. Armin Ronacher schreibt dies auch so in seinem Blog. Gerade der Umstand dass nicht alle Module in Python 2 problemlos mit Unicode umgehen können ist schon in Grund für Python 3. Natürlich wäre es wohl möglich und besser gewesen man hätte die Module gefixt. Aber hier spielt wohl auch mit dass die Leute zu Python 3 gezwungen werden sollen. Bisher konnte ich keine nennenswerten Encoding-Probleme mit Python 3 feststellen. Aber was mich bei Python wirklich nervt ist der GIL. Ich hoffe dass dieses Problem mit Python 3.5 endlich behoben wird. Man darf gespannt sein.
"Die PyPy-Variante für Python 3 machte offenbar keine Fortschritte, "
Beim 3er Monty solls ja auch so sein, daß viele nicht vom 2er aufs 3er umsteigen, weils nicht lohnt und frameworks etc n icht unterstuetzt werden und so komplett.
Wär doof, wenn Python den Javaweg geht. Ewig Potential, aber dann, naja, gruetze werden. Nix gegen java, aber ich find python besser oder eher schoener, Qualitaet kann ich nicht wirklich beurteilen.
Da hilft nur der Canonical-Weg -> den Python 2.x Sachen den Saft abdrehen.
Also ich nutze bei neuen Projekten nur mehr Python 3. Hauptgrund dafür sind die Encodingprobleme in Python 2. Was ich in Python 2 dafür schon Zeit verschwendet habe... Außerdem gibt es mittlerweile alle Module, die ich brauche auch schon für Python 3.
Ich hatte noch NIE ein Encoding Problem. Keine Ahnung was du da machst.
Python3 "versteckt" vieles besser vor dem Benutzer, ähnlich wie Java oder andere Sprachen es machen, da es auf das System weite Default Encoding bei allen IO-Operationen setzt.
Dies ist imho leider eine schlechte Entscheidung, weil sie die Portabilität von Code erschwert. Solange man nur auf seinem System arbeitet (ergo für sich entwickelt), wird man unter Linux aktuell kaum Probleme spüren, sofern utf-8 als Default Encoding eingestellt ist.
Naja, das bessere String-Konzept hat schon Python 3 - von "Encoding-Problemen" befreit das aber gar nicht, schließlich müssen die Bytes ja irgend wie in einen (Unicode-)String reinkommen.
Zu Python 2 ist ein Entwickler eben früh darauf aufmerksam geworden, nun wird er es erst spät.
Ich wäre für UTF-8 als Default-Encoding gewesen. Damit hätte man eine fixe Konvention gehabt und alles wäre gut.
Hat man das Unicode-Prinzip von Python 2.x erst einmal verstanden, ist es eigentlich sehr sinnvoll, die klare Trennung der beiden Stringtypen ist leicht zu durchschauen.
Das einzige Problem von Python 2.x sind die mitgelieferten Libs, welche Teils zickig auf Unicode-String reagieren. Für einige hat man Workarounds geliefert (codecs), was man sicher hätte auch anders lösen können.
Eigentlich wäre ein Ändern des Stringsystems gar nicht nötig gewesen, man hätte eben nur die Libs aufräumen und korrigieren müssen, dann wäre es für die meisten User schon optimal gewesen.
Einige Anpassungen, wie das Ändern von "print" waren IMHO unnötig, wenn auch nicht dramatisch.
Zu Anfang war ich Python 3.x noch deutlich positiver eingestellt, vor allem aber weil ich das Unicode-Modell von Python 2.x nicht verstand. Als mir klar wurde, das meine Probleme eher die Schuld der Libs, als denn von Python selbst waren, änderte sich meine Meinung jedoch.
Definiert man beim laden von Daten, sowie bei der Ausgabe, sauber die Encodierung, kann ich keine Probleme mit Python 2.x feststellen.
Meine Anwendungen nutzen schon heute nur Unicode, trotzt Python 2.x, und es läuft damit sehr gut. Auch ist der Quellcode dadurch kein Stück größer, als er es mit Python 3.x wäre.
Das dürfte auch das wesentliche Problem von Python 3.x sein: Erfahrene Entwickler brauchen es nicht, stören sich aber am Wechsel, der ihnen einen nutzlosen Aufwand bringt.
Diese wiederum raten unerfahrenen Entwickler aber von Python 3.x ab, da sich die Masse der Entwickler eben bei 2.x befindet.
Zumal ich nicht davon überzeugt bin, das Python 3.x am Ende wirklich besser ist. Python 2.x zwingt einen Entwickler oftmals dazu klar zu definieren, um welches Encoding es sich handelt, außer es spielt keine Rolle (z.B. weil es nie ausgegeben wird). Dies klare Linie macht es am Ende einfach sauberen Code zu schreiben, da eigentlich alles von außen erstmal undefiniert ist.
Python 3.x geht aber von einer Unicode Welt aus, die es allerdings gar nicht gibt unter Linux. Hier kann und wird oftmals ein Mix vorliegen, womit man dann eher in Probleme läuft. Doch da Python in 90% der Fälle recht hat, wägt man sich in einer Sicherheit, die es nicht gibt. Am Ende muss man Python 3.x genauso auf die Details hinweisen, nur ist es doch aktuell weniger klar beschrieben, und es gibt neue und wenig bekannte Stolperfallen.
Ein paar nette Zeilen dazu von Armin Ronacher finden sich in dessen Blog: http://lucumr.pocoo.org/
Meine Erfahrungen mit Python 3.x sehen dann auch so aus: In einer reinen Unicode-Welt ist es einfacher damit zu arbeiten, in einer Mixed-Welt hingegen eher sogar schwerer. Da die Realität jedoch oftmals eher ein Mix ist, macht es Python 3.x sogar aufwendiger, sauberen Code zu schreiben.
Ich schreib nur noch Hybride weshalb ich das Konzept von Python 2 recht einleuchtend finde. Wie du schon erwähnt hast, gibts einige Standardbibliotheken die gar nicht mit Unicode können. Und da wir in keiner perfekten Welt leben und mir so vorkommt das latin genauso häufig anzutreffen ist wie utf-8, kommt man bei Python3 auch nicht um das Problem von Encoding herum. Generell bin ich mehr ein Freund von explizit angeben, statt sich auf dem Default zu verlassen. Letzteres hat dazu geführt, dass bereits in der 2er Linie viel Code gibt, der nicht mehr korrekt funktioniert weil man open als Standard Text statt Binär öffnet.
Da ich leider unter und für Windows entwickeln muss ist für mich Python 3 die bessere Wahl. Armin Ronacher schreibt dies auch so in seinem Blog. Gerade der Umstand dass nicht alle Module in Python 2 problemlos mit Unicode umgehen können ist schon in Grund für Python 3. Natürlich wäre es wohl möglich und besser gewesen man hätte die Module gefixt. Aber hier spielt wohl auch mit dass die Leute zu Python 3 gezwungen werden sollen. Bisher konnte ich keine nennenswerten Encoding-Probleme mit Python 3 feststellen. Aber was mich bei Python wirklich nervt ist der GIL. Ich hoffe dass dieses Problem mit Python 3.5 endlich behoben wird. Man darf gespannt sein.
Wird nie kommen weil CPython einfach verständliche Referenz sein soll.