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.
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.