), war Python 3 noch nicht wirklich Thema (ich begann damals mit 2.6). Als nächstes muss ich allerdings die eine und andere Encoding-Sünde bereinigen und stehe auch deshalb vor der Frage, ob ich mein Programm weiterhin (nur Python 2) oder (Python 2 und 3) oder (nur Python 3) lauffähig gestalten sollte.
)
Eine Antwort darauf, welchen Vorteil eine Migration auf Python 3 brächte, ist es ja irgendwie schon...BlackJack hat geschrieben:Ich würde vorerst bei Python 2 bleiben. Hilft Dir so eine total subjektive Aussage jetzt echt weiter?
Gerade bei unicode literals ist das eine Vereinfachung, doch ohne weitere Weichen (z. B. range/xrange) geht's nicht. Das ist eben auch die Frage, ob ich mir das antun möchte...sparrow hat geschrieben:Nach Möglichkeit unter beidem lauffähig. Das geht mit 2.7 und __future__ ganz gut.
) )Verstehe ich jetzt nicht. Python 3 kodiert doch nicht?BlackJack hat geschrieben:Und die Default-Kodierung halte ich für einen dummen Fehler.
)Ersteres muss noch mit ``try ... except`` geschmückt werden, was die Sache nicht mehr so schön macht. Letzteres zwingt zu einer zusätzlichen Abhängigkeit.BlackJack hat geschrieben:@snafu: Ein bedingtes ``range = xrange`` oder ``from six.moves import xrange`` ist nicht sooo hässlich, finde ich.
Ja, finde das auch besser, das Aliasing an ``six`` auszulagern als das Rad ggf. nochmal in schlechter zu erfinden.BlackJack hat geschrieben:Also dann entweder ``from my_porting_utils import *`` oder ``from six.moves.builtins import *`` am Anfang vom Modul. Und da handele ich mir lieber eine zusätzliche Abhängigkeit ein, in der mir schon jemand die Arbeit abgenommen hat, als `six` noch mal selber neu zu erfinden. Das ist ein kleines Paket und soweit ich das sehe reines Python. Also keine Abhängigkeit vor der man Angst haben muss.
Ob nun ASCII oder per default UFT-8: Der Anfänger bekommt Probleme dann doch nur mit, wenn es halt nicht klappt und das ist nur der Fall, wenn er bei ASCII nicht Englischen Texte nutzt oder bei UTF-8 eigentlich nie?BlackJack hat geschrieben:@mutetella: Doch Python 3 geht an vielen Stellen wo Python 2 von ASCII ausgegangen ist, nun von der „Systemkodierung” aus. Wo man in Python 2 also mit Zeichen ausserhalb von ASCII auf die Nase gefallen ist und sich gefälligst Gedanken machen musste, funktioniert das in Python 3 einfach so. Der Haken: Es funktioniert nur solange man auf dem selben System mit der selben „Systemkodierung” ist. Wenn man also ordentlich Programmieren will, muss man nach wie vor überall an den „Grenzen” explizit eine Kodierung angeben. Nur werden insbesondere Anfänger auf diesen Umstand nicht mehr mit der Nase gestossen. Die finden das dann erst heraus wenn sie mit einem selbstgeschriebenen Programm einen Haufen Text in Dateien gespeichert haben, und das dann auf ein anderes System transferieren und dort dann feststellen dass das selbe Programm die eigenen Text-Dateien nicht mehr problemlos lesen kann, die es zuvor geschrieben hat. Das ist doch ganz grosse #&%!$…
An der Stelle hätte ich mir gewünscht, das als Default-Kodierung wenn man nichts angibt, systemunabhängig UTF-8 verwendet wird. Das kann alles kodieren was man in Unicode-Zeichenketten steckt, und man kann Programme und Daten problemlos zwischen Systemen austauschen.
Wieso sollte man auf Stdout (über ``print``) immer die Systemkodierung nutzen wollen?Vorteil ist ja dass du in Python 3 auch deine eigene ``print``-Funktion schreiben kannst und sie dann ``print`` heißt. Wobei das wohl mit future-Import in Python 2.7 auch geht.Hyperion hat geschrieben:Richtig ätzend ist ja auch, dass ich bei ``print`` keine Codierung angeben kann
Sicher, aber dann müsste man sich ja erst "Mühe" machen. Von etwas so wichtigen wie ``print`` erwarte ich einfach, dass es gut funktioniert.Leonidas hat geschrieben: Vorteil ist ja dass du in Python 3 auch deine eigene ``print``-Funktion schreiben kannst und sie dann ``print`` heißt. Wobei das wohl mit future-Import in Python 2.7 auch geht.
